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 .
Examiner’s Note (EN)
The prior art rejections below cite particular paragraphs, columns, and/or line numbers in the references for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 5-8 and 15-18 are rejected under 35 U.S.C. 112(b) for using the word ‘means’ in a method claim. ‘means’ normally invokes 112(f) interpretation in apparatus claims. However, in method claims if 112(f) is invoked, the algorithm for implementing the function of the ‘means’ needs to be disclosed. The use of the word module, function, compiler or the like would overcome the 112(b) rejection.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 2, 5, 10-12, 15, and 20-22 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Lattner et al. (US20150347102A1).
Regarding Claim 1, Lattner teaches a language interoperation method, the method comprising: obtaining code in a first language and code in a plurality of second languages ([0007] "perform operations comprising receiving a first request to compile a first set of program instructions coded in a first high-level language. The first high-level language can be a C language based object-oriented programming language. The operations can further include receiving a second request to compile a second set of program instructions related to the first set of program instructions. The second set of instructions can be coded in a second high-level language that includes both object-oriented elements and procedural elements. The instructions in the second set of program instructions are not strictly compatible with the C programming language.")
generating a unified abstract representation of interoperation boundary information of the plurality of second languages based on the code in the plurality of second languages ([0008] "The operations can additionally include compiling the first set of program instructions and the second set of program instructions using a modular compilation system. The modular compilation system can include multiple front-end compilers, the first set of program instructions compiled into a first intermediate representation of the first set of program instructions and the second set of program instructions compiled into a second intermediate representation of the second set of program instructions." [0098] "Each of the multiple front-end compilers can convert source code written in a particular high-level language into a common intermediate representation, such as, for example, the LLVM intermediate representation. A linker 105 can link function and object references between the code modules compiled by the front-end compilers before an intermediate language optimizer 106 can then perform cross-language optimization on the intermediate representation. In one embodiment, the intermediate language optimizer 106, based on one or more requested compile-time optimizations, performs one or more additional link-time optimizations on the resulting intermediate representations output by the multiple front-end compilers. (e.g., cross-module dead code stripping, etc.). Thus, multiple software modules written in multiple high-level source code languages can be optimized at a common point and then cross-optimized, even though the modules were each coded in different high-level languages." and [0114])
the unified abstract representation comprising binary code of the interoperation boundary information of the plurality of second languages ([0099] "The intermediate representation can be stored in a text-based intermediate language or converted into a bitcode representation. The intermediate representation can then be converted by one or more back-end compilers into a machine-language format that is specific to a particular processor architecture.")
the interoperation boundary information of the plurality of second languages representing constituent elements allowing mutual access or use with the first language among constituent elements of the plurality of second languages ([0009] "The application development system includes a modular compilation system having a first-front end compiler and a second front-end compiler, and additionally includes a linker to link symbolic references to functions in the first and second set of program instructions. The first high-level language can be a C language based object-oriented programming language. The second high-level language includes object-oriented elements and procedural elements and is not strictly compatible with the C programming language." [0098] "A linker 105 can link function and object references between the code modules compiled by the front-end compilers before an intermediate language optimizer 106 can then perform cross-language optimization on the intermediate representation." [0096] "The modules of the mixed language framework can be accessed from client software developed in both the C-compatible language, as well as modules developed in the new language. When cross-importing modules coded in differing languages the programming system can automatically generate header files that incorporate sufficient bridging information to exposes functionality across modules coded in differing languages. In one embodiment, a bridging header file is automatically generated that includes the necessary information required to perform link time symbol resolution with external modules coded in a differing language. Mixed language development is enabled in part by the modular compiler system used by the programming system described herein." [0104] " In one embodiment, the operating system 222 includes a loader/linker 227 having a load/link optimizer 228 to perform additional link-time and load-time optimizations while loading components of the application into process memory space 240. An example link-time optimization is to bypass the loading of a program function if the function is not called by any other function (e.g., the linker does not resolve any symbols to the function). Should the function become relevant at a later time, the loader/linker 227 may load the function in memory.")
compiling the code in the first language, based on the unified abstract representation, to obtain and output binary code of the code in the first language ([0097-0098] "In one embodiment, compilation of the new language can be performed within an integrated development environment using a modular compiler system, such the system enabled by the LLVM compiler infrastructure. In one embodiment, a front-end compiler such as the Clang front-end compiler can be used. FIG. 1 is a block diagram illustrating an embodiment of a modular compiler system 100 with support for the new language. In one embodiment the modular compiler system 100 includes multiple front-end compilers, including a first front-end compiler 102 having support for the new language and a second front-end compiler 104 having C-language support (e.g., C, Objective-C). Each of the multiple front-end compilers can convert source code written in a particular high-level language into a common intermediate representation, such as, for example, the LLVM intermediate representation. A linker 105 can link function and object references between the code modules compiled by the front-end compilers before an intermediate language optimizer 106 can then perform cross-language optimization on the intermediate representation. In one embodiment, the intermediate language optimizer 106, based on one or more requested compile-time optimizations, performs one or more additional link-time optimizations on the resulting intermediate representations output by the multiple front-end compilers. (e.g., cross-module dead code stripping, etc.). Thus, multiple software modules written in multiple high-level source code languages can be optimized at a common point and then cross-optimized, even though the modules were each coded in different high-level languages.")
wherein when the binary code of the code in the first language is executed, a constituent element in the code in the first language and a constituent element of any one of the plurality of second languages are mutually accessible or usable ([0096] and [0104])
Regarding Claim 2, Lattner teaches The method according to claim 1. Lattner further teaches wherein the generating the unified abstract representation of the interoperation boundary information of the plurality of second languages based on the code in the plurality of second languages comprises:
recognizing the interoperation boundary information of the plurality of second languages based on the code in the plurality of second languages ([0096] and [0098] "Each of the multiple front-end compilers can convert source code written in a particular high-level language into a common intermediate representation, such as, for example, the LLVM intermediate representation. A linker 105 can link function and object references between the code modules compiled by the front-end compilers before an intermediate language optimizer 106 can then perform cross-language optimization on the intermediate representation. In one embodiment, the intermediate language optimizer 106, based on one or more requested compile-time optimizations, performs one or more additional link-time optimizations on the resulting intermediate representations output by the multiple front-end compilers. (e.g., cross-module dead code stripping, etc.).")
generating the unified abstract representation based on the interoperation boundary information of the plurality of second languages ([0096] and [0098])
Regarding Claim 5, Lattner teaches the method according to claim 1. Lattner further teaches wherein the compiling the code in the first language based on the unified abstract representation to obtain and output the binary code of the code in the first language comprises: obtaining, based on a difference between the unified abstract representation and interoperation boundary information of the first language, a processing means for processing semantics of the unified abstract representation and the first language, wherein the interoperation boundary information of the first language is determined based on the code in the first language ([0096] and [0098])
compiling the code in the first language by using the processing means to obtain and output the binary code of the code in the first language([0098-0099] EN: The linker uses the IR to link between the different languages. The code is further compiled after including the necessary linking functionality and optimizing it into a bitecode representation)
Regarding Claim 10, Lattner teaches the method according to claim 1. Lattner further teaches wherein: interoperation boundary information of different second languages is not completely the same ([0003-0004] “One front end used by LLVM is Clang, which is a C language front-end for LLVM. Generically, the C language is a general-purpose programming language that has been closely associated with the UNIX operating system. However, the C language has found use in nearly all aspects of software development. Clang can be used as a front-end compiler for software written in Objective-C. Objective-C is a superset of the C programming language and provides object-oriented capabilities and a dynamic runtime. Objective-C inherits the syntax, primitive types, and flow control statements of C and adds syntax for defining classes and methods. Objective-C also adds language-level support for object graph management and object literals while providing dynamic typing and binding, deferring many responsibilities until runtime. Objective-C is a ‘strict superset’ of C. The syntax for non-object-oriented operations, including primitive variables, pre-processing, expressions, function declarations, and function calls are identical to that of C, while the syntax for object-oriented features is an implementation of messaging derived from the Smalltalk object-oriented language. Accordingly, it is possible to compile any C program with an Objective-C compiler, and to freely include C code within an Objective-C class.” EN: both C and Objective-C are possible second languages and they’re interoperation boundary are not completely the same)
Regarding Claim 11, Lattner teaches A language interoperation apparatus, comprising: a memory storing instructions; and at least one processor in communication with the memory, the at least one processor configured, upon execution of the instructions, to perform the following steps: ([0007] “In one embodiment a non-transitory computer-readable medium with instructions stored therein cause a processing system including one or more processors to perform operations comprising”)
The remaining limitations are similar to claim 1 and are rejected under the same rationale.
Claims 12, 15 and 20 are apparatus claims reciting limitations similar to claims 2, 5 and 10 respectively and are rejected under the same rationale.
Regarding Claim 21, Lattner teaches a non-transitory computer-readable media storing computer instructions that configure at least one processor, upon execution of the instructions, to perform the following steps: ([0007] “In one embodiment a non-transitory computer-readable medium with instructions stored therein cause a processing system including one or more processors to perform operations comprising”)
The remaining limitations are similar to claim 1 and are rejected under the same rationale.
Claims 22 is a medium claims reciting limitations similar to claims 2 and is rejected under the same rationale.
Claim Rejections - 35 USC § 103
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.
Claims 3-4, 13-14 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Lattner et al. (US20150347102A1)
Regarding Claim 3, Lattner teaches the method according to claim 1. Lattner further teaches wherein the interoperation boundary information of the plurality of second languages comprises at least one repeated constituent element and at least one unique constituent element, the at least one repeated constituent element repeatedly appears among the constituent elements comprised in the interoperation boundary information of the plurality of second languages, and the at least one unique constituent element appears only once among the constituent elements comprised in the interoperation boundary information of the plurality of second languages (EN: [0113] of the instant specification defines repeated to mean common/shared between languages and unique to mean specific/unique to a language. The claim is interpreted as such in light of the specification. [0009] "a linker to link symbolic references to functions in the first and second set of program instructions. The first high-level language can be a C language based object-oriented programming language. The second high-level language includes object-oriented elements and procedural elements and is not strictly compatible with the C programming language." [0004] "Objective-C is a ‘strict superset’ of C. The syntax for non-object-oriented operations, including primitive variables, pre-processing, expressions, function declarations, and function calls are identical to that of C, while the syntax for object-oriented features is an implementation of messaging derived from the Smalltalk object-oriented language" EN: example of unique constituents are elements specific to Objective-C that are not components in C, while examples of repeated constituents are elements shared between C, Objective-C, and C++ for example. [0096], [0098], and [0104] cover the bridging/IR)
Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to understand Lattner’s support for different C languages like Objective-C, and C/C++ would constitute support for repeated and unique constituent element, repeated indicating shared between languages and unique indicating language specific elements. [0004] "Objective-C is a ‘strict superset’ of C. The syntax for non-object-oriented operations, including primitive variables, pre-processing, expressions, function declarations, and function calls are identical to that of C, while the syntax for object-oriented features is an implementation of messaging derived from the Smalltalk object-oriented language"
Regarding Claim 4, Lattner teaches the method according to claim 1. Lattner further teaches wherein the interoperation boundary information of the plurality of second languages comprises a common part and a special part, wherein: each constituent element in the common part corresponds to at least two of the plurality of second languages; and each constituent element in the special part corresponds to only one of the plurality of second languages (EN: [0111] of the instant specification describes common to contain 'repeated' constituents ie, common/shared between languages and special to contain ‘specific/unique’ constituents to a language. The claim is interpreted as such in light of the specification. [0009] "a linker to link symbolic references to functions in the first and second set of program instructions. The first high-level language can be a C language based object-oriented programming language. The second high-level language includes object-oriented elements and procedural elements and is not strictly compatible with the C programming language." [0004] "Objective-C is a ‘strict superset’ of C. The syntax for non-object-oriented operations, including primitive variables, pre-processing, expressions, function declarations, and function calls are identical to that of C, while the syntax for object-oriented features is an implementation of messaging derived from the Smalltalk object-oriented language" EN: example of unique constituents are elements specific to Objective-C that are not components in C, while examples of repeated constituents are elements shared between C, Objective-C, and C++ for example. [0096], [0098], and [0104] cover the bridging/IR)
For motivation to combine see claim 3.
Claims 13-14 are apparatus claims reciting limitations similar to claims 3-4 respectively and are rejected under the same rationale.
Claim 23 is a medium claims reciting limitations similar to claim 3 and is rejected under the same rationale.
Claims 6, 9, 16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lattner et al. (US20150347102A1) in view of Jiang et al. (WO2020192667A1)
Regarding Claim 6, Lattner teaches the method according to claim 5. Jiang further teaches wherein the processing means comprises mapping processing, wherein the mapping processing comprises: compiling, based on a data type of corresponding memory in a mapping relationship, the constituent element that is in the code in the first language and that uses a same memory as a constituent element of the unified abstract representation but has a different name, wherein the mapping relationship indicates a correspondence between the constituent element of the unified abstract representation, a constituent element of the interoperation boundary information of the first language, and data types of different memory ([0094] “Figure 7 illustrates an example of an interface function hash table and a collision elimination table for class A. In the hash table, based on the hash value of the function signature of fooC, the function pointer corresponding to fooC is filled into the corresponding position. Fill in 0 for positions where there is no corresponding function or where there is more than one corresponding function (a conflict has occurred). When a conflict occurs, for example, if the hash value of the signature of fooB is the same as the hash value of the signature of fooD, the conflict resolution table stores the signature of each function and the corresponding function address. Since the calculation of the interface function table and the function signature hash value is completed at compile time, a variable-length hash table can be used, and various hash functions can be tried to reduce collisions and reduce the size of the hash table, thereby reducing memory consumption and improving virtual call performance.” [0099-0100] “In some implementations, the intermediate language code generates the data required for non-native language reflection, including class metadata, class field information, and class method information. For example, when the non-native language is Java, JNI interface functions such as GetMethodID and CallVoidMethod are converted into Intrinsic by using the class's metadata, field information, and method information, and the semantics of these Intrinsic functions are known to the compiler. For example, in Figure 8, box A shows a code example of a C/C++ call to a Java function. Boxes B, C, and D respectively show the data structures for the class's metadata, method information, and field information generated in the intermediate language code during compilation.”)
PNG
media_image1.png
526
702
media_image1.png
Greyscale
Lattner and Jiang are analogous art because they are from the same field of endeavor in code cross language communication and compiling. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Lattner and Jiang to incorporate Jiang’s more explicit mapping methodology for cross calling functions and objects across the plurality of languages with expected results. “In some implementations, the invocation function in the intermediate language is used to complete, at runtime, the invocation between the function converted from the non-native language and the function converted from the native language with reference to the function converted from the non-native language and the function converted from the native language.” (Jiang, [0010])
Regarding Claim 9, Lattner teaches the method according to claim 1. Jiang further teaches wherein the compiling the code in the first language based on the unified abstract representation to obtain and output binary code of the code in the first language comprises: when constituent elements with a same name but different syntax exist in the unified abstract representation and interoperation boundary information of the first language, adding, to a constituent element of the first language, a tagged constituent element corresponding to a constituent element of the unified abstract representation to obtain and output the binary code of the code in the first language; wherein a tag of the tagged constituent element indicates that when the tagged constituent element in the code in the first language is executed, syntax of the constituent element of the unified abstract representation is implemented ([0099-0100] [0101-0111] cover the steps in detail. [0112] “As shown in Figure 9, the Java class Callbacks declares a call to a C/C++ function nativeMethod. Box B describes the definition of the C/C++ function nativeMethod. nativeMethod ultimately calls the class method callback of the Callbacks class by calling the JNI interface functions GetObjectClass, GetMethodID, and CallVoidMethod. For standard JNI, the function to be called can only be found at runtime through the parameter obj. In this example, since the methods in box A and box B are both converted into intermediate language representations, the compiler can simultaneously obtain the inheritance relationship of the Callbacks class and the definition of the function nativeMethod. Therefore, the inheritance relationship of the Java-side Callbacks class can be passed to the C/C++ side through the compiler. After the compiler understands the semantics of the JNI interface function, it can analyze and determine that CallVoidMethod ultimately calls the class method callback of the Callbacks class. Therefore, functions like those in box C can be generated in the intermediate code. Compared to the nativeMethod function in box B, the function in box C has removed one parameter (JNI interface pointer) and the original JNI interface function call. The function in box C can be used for mutual invocation between the native language method (nativeMethod) and the non-native language method (callback).”)
PNG
media_image2.png
489
709
media_image2.png
Greyscale
For motivation to combine please refer to claim 6.
Claims 16 and 19 are apparatus claims reciting limitations similar to claims 6 and 9 respectively and are rejected under the same rationale.
Claims 7-8 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Lattner et al. (US20150347102A1) in view of Deng et al. (US20210357192A1)
Regarding Claim 7, Lattner teaches the method according to claim 5. Deng further teaches wherein a constituent element variable of the unified abstract representation comprises a null pointer, a constituent element variable of the first language does not comprise a null pointer([0031-0032] "An interprocedural analysis spans multiple files or methods, including all the methods in the entire program. An interprocedural static code analysis is able to detect memory safety faults or bugs that span multiple files or methods, such as null pointer dereferencing and memory leaks, which would be missed if intraprocedural static analysis were used. Null pointer dereference occurs when the program dereferences a pointer that it expects to be valid, but is null, or points to memory that has not been allocated. Null pointer dereferences typically cause the program to crash or exit. ….In one aspect, the interprocedural static code analyzer 134 is Facebook®'s Infer. Infer is based on separation logic that performs Hoare-logic reasoning about programs that mutate data structures. Infer uses the analysis language, Smallfoot Intermediate Language (SIL), to represent a program in a simpler instruction set that describes the program's actions on a symbolic heap." EN: the abstract representation tests for null pointers and is able to detect Null pointer dereferences that would normally cause the program written in a language that doesn't allow a null pointer to crash. [0041-0059] further describe the construction of the IR and the analysis across the various languages to determine if a null pointer will result and it then throws a bug alert.)
the processing means comprises first runtime conversion processing; wherein the first runtime conversion processing comprises: when determining, using runtime conversion code, that the runtime is null, throwing a currently compiled constituent element variable as an exception ([0034] "The interprocedural static code analyzer 134 generates results that may indicate a potential bug or memory safety fault within the program. The results 136 are output to a bug report generator 138. The results 136 indicate the file name and line of the detected bug. The results may be output in a bug report 140. Alternatively, the bug report generator 138 may map the location of the bug back to the original source code which may be displayed in a user interface along with the original source code.")
Lattner and Deng are analogous art because they are from the same field of endeavor in code cross language communication. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Lattner and Deng to incorporate Deng’s pointer handling and exception throwing mechanisms with Lattner’s cross language compiling functionality with expected results . “An interprocedural analysis spans multiple files or methods, including all the methods in the entire program. An interprocedural static code analysis is able to detect memory safety faults or bugs that span multiple files or methods, such as null pointer dereferencing and memory leaks, which would be missed if intraprocedural static analysis were used. Null pointer dereference occurs when the program dereferences a pointer that it expects to be valid, but is null, or points to memory that has not been allocated. Null pointer dereferences typically cause the program to crash or exit.” (Deng, [0031])
Regarding Claim 8, Lattner teaches the method according to claim 5. Deng further teaches wherein a constituent element variable of the unified abstract representation comprises a null pointer, a constituent element variable of the first language does not comprise a null pointer, and the processing means comprises second runtime conversion processing ( [0031-0032])
Lattner further teaches wherein the second runtime conversion processing comprising: when determining, using runtime conversion code, that the runtime is null, returning a null value in an optional constituent element ([0022] "In one embodiment, an optional type is provided that handles the absence of a value. Optionals are a way to say either “there is a value, and it equals x” or “there isn't a value at all.” Optionals do not exist in C or Objective-C. The nearest analogy in Objective-C is the ability to return nil from a method that would otherwise return an object, with nil meaning “the absence of a valid object.” However, this only works for objects and does not work for structs, basic C types, or enumeration values. For these types, Objective-C methods typically return a special value (e.g., NSNotFound) to indicate the absence of a value. This assumes that the method's caller knows there is a special value to test against and remembers to check for it. To the contrary, optionals allow a developer to indicate the absence of a value of any type, without the use of special constants." and "Optional chaining is a way to query and call properties, methods, and subscripts on an optional that might currently be nil. An optional value either contains a value or contains nil to indicate that the value is missing. A ‘?’ applied to a type indicates that the type may have a value, or that the value may optionally be nil (e.g., contains no value). Control flow can be performed using optional values, such that if an optional contains a value, the property, method, or subscript call succeeds; if the optional is nil, the property, method, or subscript call returns nil. Multiple queries can be chained together, and the entire chain fails gracefully if any link in the chain is nil.").
For motivation to combine please refer to claim 7.
Claims 17 and 18 are apparatus claims reciting limitations similar to claims 7 and 8 respectively and are rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kotlin (Github:JetBrains/Kotlin-web-site): discusses interoperability between Kotlin and Java including explicitly throwing exceptions when an object value is null or optionally passing a value as recited in claims 7 and 8.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR DARWISH whose telephone number is (571)272-4779. The examiner can normally be reached 7:30-5:30 M-Thurs.
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, Emerson Puente can be reached on 571-272-3652. 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.
/A.E.D./Examiner, Art Unit 2187
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199