DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-13 and 20-23 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-13 and 20-23 are rejected under 35 U.S.C. 103 as being unpatentable over Kaksonen (US 2009/0204591 A1)in view of Cecchetti et al. (US 2016/0350211 A1).
Regarding claims 1 and 20, Kaksonen teaches a method performed by fuzz testing
equipment for fuzz testing a system under test, SUT (see claim 10) configured for use in a
wireless communication network (see par. 0035: The messaging may use e.g. any suitable
networking means, e.g. wireline or wireless networks or other suitable communication means,
e.g. Ethernet network, WLAN, USB cable, serial connection, or Bluetooth connection)/ Fuzz
testing equipment for fuzz testing a system under test, SUT, configured for use in a wireless
communication network, the fuzz testing equipment comprising: communication circuitry; and
processing circuitry configured to, the method comprising: obtaining a message specification that
governs a certain type of message whose handling by the SUT is to be tested (see pars. 0011-
0013: constructing instance data of test cases using data of a test design library; The protocol
model may e.g. describe the syntax of the protocol messages and message sequences. The model
may be defined by various formal notations known in the art, such as ASN.1, ABNF and XML.
The protocol model may comprise information describing the actual semantic meaning and/or
data type of value of data items of a test case instance); mutating the message specification (see
paras 78-97, the design library contains data which extend the data required by the protocol with
invalid data, i.e. a mutated specification); and performing, or assisting with, testing of the SUT
using a message that is fuzzed based on the mutated message specification (paras 42-83, message
is built thanks to the design library which contains also invalid data, i.e. data according to the
mutated specification). Kaksonen does not clearly mention the fuzz testing equipment being implemented in a radio network node and the SUT being a wireless communication device. Cecchetti et al. teach the fuzz testing equipment being implemented in a radio network node (see fig. 1: Network Whitebox Fuzzer Component (NWFC) 110) and the SUT being a wireless communication device (see fig. 1: Target Network Component (TC) 102) (see fig. 1 and fig. 11; pars. 0125-0126: FIG. 11 describes software that acts as an intermediary between users and computer resources described in suitable operating environment 1100; fuzzing parameters related to fuzzing data to be passed into the TC at a state input point, e.g., 162, 262, 362, 462, 562, etc., by way of a user interface embodied in a touch sensitive display panel, keyboard, mouse, etc., allowing a user to interact with the fuzzing operations via computer 1112. Input devices 1136 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, cell phone, smartphone, tablet computer, etc.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective the filling date of claimed invention (AIA ) to modify the fuzz testing equipment being implemented in a radio network node and the SUT being a wireless communication device of Cecchetti et al. to the method of Kaksonen in order for fuzzing can facilitate identification of issues, for example, in a run time environment, heap corruption, a use-after-free bug, a memory disclosure, etc. in a wireless network.
Regarding claims 2-3 and 21-22, Kaksonen also teaches wherein the message
specification specifies one or more requirements in order for a message to conform to the
message specification, and wherein said mutating comprises mutating at least one of the one or
more requirements; wherein mutating at least one of the one or more requirements includes
relaxing at least one of the one or more requirements (see paras 36-52 and 79-97, also invalid
data are contained in design library containing the mutated specification).
Regarding claims 4 and 23, Kaksonen also teaches wherein at least of: the one or more
requirements include a field value requirement, wherein the field value requirement requires a
field of a message of the certain type to have a value included in a set of one or more valid
values in order for the message to conform to the message specification, and wherein mutating at least one of the one or more requirements comprises relaxing the field value requirement by
adding one or more additional valid values to the set of one or more valid values; the one or
more requirements include a data type requirement, wherein the data type requirement requires a
field of a message of the certain type to have a certain data type in order for the message to
conform to the message specification, and wherein mutating at least one of the one or more
requirements comprises changing the data type requirement to require the field of the message to
have a different data type; the one or more requirements include a field name requirement,
wherein the field name requirement requires a field of a message of the certain type to have a
certain name in order for the message to conform to the message specification, and wherein
mutating at least one of the one or more requirements comprises changing the field name
requirement to require the field of the message to have a different name; the one or more requirements include a field value length requirement, wherein the field value length requirement
requires a value of a field of a message of the certain type to have a certain length in order for the
message to conform to the message specification, and wherein mutating at least one of the one or
more requirements comprises changing the field value length requirement to require a value of
the field of the message to have a different length; or the one or more requirements include a
field requirement, wherein the field requirement requires a message of the certain type to have a
set of one or more required fields in order for the message to conform to the message
specification, and wherein mutating at least one of the one or more requirements comprises
adding a required field to the set and/or removing a required field from the set (see par. 0097: he
kind of values which can be stored in the design library 201 and accessed by keys containing
data type and/or semantic value. Further, as an example, the "keys" may be database fields,
wherein the test design library 201 comprises a database table stored on the repository 101, said
database table comprising records having dedicated key fields containing identifiers for data type
and/or semantic value).
Regarding claim 5, Kaksonen also teaches wherein said performing comprises: fuzzing a
message of the certain type based on the mutated message specification; and testing the SUT by
sending the fuzzed message to the SUT (See abstract).
Regarding claims 6-7, Kaksonen also teaches wherein fuzzing the message of the certain
type based on the mutated message specification comprises: compiling, based on the mutated
message specification, a message data structure that defines a data structure of a message
conforming to the mutated message specification; and obtaining the fuzzed message as a
message that has a data structure defined by the compiled message data structure (see pars. 0013
and 0022); wherein the message specification and the mutated message specification are each
specified in terms of an interface description language which is programming language agnostic,
and wherein the compiled message data structure defines a programming language specific data
structure of a message conforming to the mutated message specification (see pars. 0013 and
0022).
Regarding claim 8, Kaksonen also teaches wherein obtaining the fuzzed message (14)
comprises: generating, from scratch, the fuzzed message (14) as a message (14) that has a data
structure defined by the compiled message data structure; or obtaining the fuzzed message (14)
as a function of a decoded nominal message and the compiled message data structure, wherein
the decoded nominal message is decoded using a message decoder compiled based on the
message specification (see par. 0142).
Regarding claim 9, Kaksonen also teaches compiling a message encoder based on the
mutated message specification (see par. 0142); and encoding the fuzzed message using the compiled message encoder; wherein sending the fuzzed message to the SUT comprises sending
the fuzzed message as encoded to the SUT (see par. 0142).
Regarding claim 10, Kaksonen also teaches wherein assisting with testing of the SUT
comprises sending the mutated message specification to other fuzz testing equipment configured
to test the SUT using a message that is fuzzed based on the mutated message specification (see
par. 0035 and fig. 1).
Regarding claims 11-12, Kaksonen also teaches wherein the message specification is
specified in an Interface Description Language, IDL; wherein the IDL is Abstract Syntax
Notation One, ASN.1 (see pars. 0013 and 0022).
Regarding claim 13, Kaksonen also teaches wherein either: the certain type of
message is a Radio Resource Control, RRC, message, and the fuzzed message is a fuzzed RRC
message; or the certain type of message is a Non-Access Stratum, NAS, message, and the fuzzed
message is a fuzzed NAS message (see par. 0035).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAVID Q NGUYEN whose telephone number is (571)272-7844. The examiner can normally be reached Monday-Friday 7:00 AM - 3:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jinsong Hu can be reached at 5712723965. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DAVID Q NGUYEN/Primary Examiner, Art Unit 2643