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 .
Drawings
The drawings Fig 3A, Fig 3B, Fig 3C, Fig 3D, Fig 3E, Fig 3F & Fig 4 are not of sufficient quality to permit examination. Accordingly, replacement drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to this Office action. The replacement sheet(s) should be labeled “Replacement Sheet” in the page header (as per 37 CFR 1.84(c)) so as not to obstruct any portion of the drawing figures. If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action.
Applicant is given a shortened statutory period of TWO (2) MONTHS to submit new drawings in compliance with 37 CFR 1.81. Extensions of time may be obtained under the provisions of 37 CFR 1.136(a) but in no case can any extension carry the date for reply to this letter beyond the maximum period of SIX MONTHS set by statute (35 U.S.C. 133). Failure to timely submit replacement drawing sheets will result in ABANDONMENT of the application.
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 of this title, 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 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ben-Aharon et al (US20160371312) in view of Andersson et al (US20220083316).
Regarding Claim 1. Ben-Aharon teaches A computer system comprising:
one or more processors;
a memory to store a set of instructions;
wherein the one or more processors that are operable to execute instructions stored in the memory to perform operations that include:
providing a design interface for a graphic design (Ben-Aharon, abstract, the invention describes a system implementable on a computing device having a processor and a memory, including a visual design system to generate a single visual data structure based on a hierarchy of components; a database to store at least one visual data structure and an associated signature where the signature represents at least a semantic composition of the at least one visual data structure; a signature comparer to match a signature of the single visual data structure to an associated signature of at least one visual data structure stored in the database and to present multiple versions of alternate visual data structure for the hierarchy of components for selection by a user; and where the alternate visual data structure are visually different and semantically similar to each other.
[0042] FIG. 2 is a schematic illustration of a sample user interface displaying a selection of possible alternative layouts for the example webpage in FIG. 1, constructed and operative in accordance with a preferred embodiment of the present invention;);
implementing a variable data structure for use with the graphic design (Ben-Aharon, [0235] For example, for a layout with 1 text, 1 video, 1 image and 1 gallery, signature extractor 147 may generate the following signatures (assuming the use of a Generic Visual composite type):
[0236] 1 Text, 1 Video, 1 Image, 1 Gallery.
[0237] 1 Text, 2 Visuals, 1 Gallery.
[0238] 1 Text, 3 GenericVisual.
[0239] 4 components.
[0240] Signature extractor 147 may therefore generate multiple signatures for both the handled component set and the indexed pages, and the searching process (as discussed in more detail herein below) may include some or all of these signatures.),
the variable data structure being defined at least in part by multiple values
and a value type (Ben-Aharon, [0252] Alternatively, signature extractor 147 may use a
stratified semantic tree as illustrated in FIG. 19 to which reference is now made, which shows a stratified version of the semantic tree shown in FIG. 17. In a stratified system, all semantic types "go up the tree" together. Thus, all level 1 (bottom of tree) semantic type entries are united into their level 2 semantic types together, and then level 3 etc.
PNG
media_image1.png
430
755
media_image1.png
Greyscale
Therefore, the data structure showed in Fig 17 indicates at least a visual data type including values such as image and video.); and
Ben-Aharon fails to explicitly teach, however, Andersson teaches linking a multi-state design element with the variable data structure, such that each state of the multiple states is based at least in part on a corresponding value of the value type (Anderson, abstract, the invention teaches an interactive graphic design system design interface is described to enable design users to create a variant component that links multiple design elements as variants, where each variant represents a state or version of a nm-time object, feature or user-interface.
[0046] According to examples, the IGDS 100 can execute variant component logic 108 to enable design users to create, modify and reuse variant components when working on the UI design under edit 125. The IGDS 100 can implement the variant component logic 108 in connection with providing the design interface 118. The IGDS 100 can implement the variant component logic 108 to define variant components to have constituent variants, with each variant being a design element (e.g., components) that is logically linked to other variants of the variant component. In particular, the variants of a variant component can share one or multiple predefined state properties, with each variant having a particular value for the state property or properties, such that each variant is unique amongst the variants of the variant component with respect to the state property values that are assigned to that variant. By way of example, the variant component can include a button, and each variant of the variant component defines a state of a run-time button feature. In such an example, the state property that may vary amongst the variants can be a fill pattern, and each variant of the variant component can be assigned to one of multiple possible property values (e.g., one of N fill patterns, where the run-time button feature is to have N states).
[0082] The IGDS 100 defines a variant component based on the received design user input (220). The design user input can specify one or multiple constituent variants that are logically linked to comprise a variant component. In variations, the design user input can specify multiple portions of a single design element or object as constituent variants of a variant component.).
Ben-Aharon and Andersson are analogous art because they both teach method of graphical user interface design by using variable data structure. Andersson further teaches using the variable data structure to control a multi-state GUI element. Therefore, it would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention, to modify the GUI design method using variable data structure (taught in Ben-Aharon), to further use the variable data structure to control the multi-state design element (taught in Andersson), so as to provide a collaborative and scalable GUI design environment that allows different designers to efficiently create components for different interactive features of the end product (Andersson, [0020-0021]).
Regarding Claim 2. The combination of Ben-Aharon and Andersson further teaches The computer system of claim 1, wherein the operations further comprise: during a design phase, performing a simulation of the graphic design when deployed in a production environment by sequentially rendering the multi-state design element in each of the multiple states based on the variable data structure (Andersson, [0082] The IGDS 100 defines a variant component based on the received design user input (220). The design user input can specify one or multiple constituent variants that are logically linked to comprise a variant component. In variations, the design user input can specify multiple portions of a single design element or object as constituent variants of a variant component.
[0087] Further, the IGDS 100 enables the user to specify one or more interactions for the variant set (260). In examples, each interaction of the variant set is defined to specify a first variant (e.g., or initial or current variant) that is to change to a second variant (e.g., target or next variant) of the variant set…. As shown by FIG. 5A and FIG. 5C, in some examples, interactions can be visually rendered as noodles or line connectors that identify a sequence as between variants, where the sequence corresponds to a state flow for the represented run-time object (262). Further, the interactions can be associated on the canvas with an event type ( e.g., trigger, input type) and other characteristics which further define the state flow for the interactive object.
[0127] Among other advantages, examples as described allow for the variants 516, 518 of the variant set 510 to be rendered at the same time, along with the interactions 522, 524, so that the states and state change behaviors of a run-time object are visually represented at the same time.).
The reasoning for combination of Ben-Aharon and Andersson is the same as described in Claim 1.
Regarding Claim 3. The combination of Ben-Aharon and Andersson further teaches The computer system of claim 1, wherein the variable data structure incudes multiple values of the value type, and wherein linking the multi-state design element includes rendering the multi-state design element in each state to include an attribute value that is specific to the state and based at least in part on a corresponding one of the multiple values of the value type (Andersson, [0046] According to examples, the IGDS 100 can execute variant component logic 108 to enable design users to create, modify and reuse variant components when working on the UI design under edit 125. The IGDS 100 can implement the variant component logic 108 in connection with providing the design interface 118. The IGDS 100 can implement the variant component logic 108 to define variant components to have constituent variants, with each variant being a design element (e.g., components) that is logically linked to other variants of the variant component. In particular, the variants of a variant component can share one or multiple predefined state properties, with each variant having a particular value for the state property or properties, such that each variant is unique amongst the variants of the variant component with respect to the state property values that are assigned to that variant. By way of example, the variant component can include a button, and each variant of the variant component defines a state of a run-time button feature. In such an example, the state property that may vary amongst the variants can be a fill pattern, and each variant of the variant component can be assigned to one of multiple possible property values (e.g., one of N fill patterns, where the run-time button feature is to have N states.
Therefore, the state property value is equivalent of attribute value that is specific to the state.).
The reasoning for combination of Ben-Aharon and Andersson is the same as described in Claim 1.
Regarding Claim 4. The combination of Ben-Aharon and Andersson further teaches The computer system of claim 1, wherein the value type of the variable data structure is a number that represents a type of design attribute for the multi-state design element (Andersson, [0043] In examples, the rendering engine 120 uses the data structure representations 111 to render a corresponding UI design under edit 125 on the canvas 122, wherein the UI design under edit 125 reflects graphic elements and their respective attributes as provided with the individual pages of the files 101. The design user can edit the UI design under edit 125 using the design interface 118. Alternatively, the rendering engine 120 can generate a blank page for the canvas 122, and the design user can use the design interface 118 to generate the UI design under edit 125. As rendered, the UI design under edit 125 can include graphic elements such as a background and/or a set of objects (e.g., shapes, text, images, programmatic elements), as well as attributes of the individual graphic elements. Each attribute of a graphic element can include an attribute type and an attribute value. For an object, the types of attributes include, shape, dimension (or size), layer, type, color, line thickness, text size, text color, font, and/or other visual characteristics. Depending on implementation, the attributes reflect properties of two- or three-dimensional designs. In this way, attribute values of individual objects can define, for example, visual characteristics of size, color, positioning, layering, and content, for elements that are rendered as part of the UI design under edit 125.).
The reasoning for combination of Ben-Aharon and Andersson is the same as described in Claim 1.
Regarding Claim 5. The combination of Ben-Aharon and Andersson further teaches The computer system of claim 4, wherein the number represent an attribute corresponding to one or more of a line attribute, a corner attribute or a size attribute (Andersson, [0043] In examples, the rendering engine 120 uses the data structure representations 111 to render a corresponding UI design under edit 125 on the canvas 122, wherein the UI design under edit 125 reflects graphic elements and their respective attributes as provided with the individual pages of the files 101. The design user can edit the UI design under edit 125 using the design interface 118. Alternatively, the rendering engine 120 can generate a blank page for the canvas 122, and the design user can use the design interface 118 to generate the UI design under edit 125. As rendered, the UI design under edit 125 can include graphic elements such as a background and/or a set of objects (e.g., shapes, text, images, programmatic elements), as well as attributes of the individual graphic elements. Each attribute of a graphic element can include an attribute type and an attribute value. For an object, the types of attributes include, shape, dimension (or size), layer, type, color, line thickness, text size, text color, font, and/or other visual characteristics. Depending on implementation, the attributes reflect properties of two- or three-dimensional designs. In this way, attribute values of individual objects can define, for example, visual characteristics of size, color, positioning, layering, and content, for elements that are rendered as part of the UI design under edit 125.).
The reasoning for combination of Ben-Aharon and Andersson is the same as described in Claim 1.
Regarding Claim 6. The combination of Ben-Aharon and Andersson further teaches The computer system of claim 1, wherein the value type of the variable data structure is a color value that represents one or more of a fill attribute, a line color attribute and/or a background attribute (Andersson, [0043] … As rendered, the UI design under edit 125 can include graphic elements such as a background and/or a set of objects (e.g., shapes, text, images, programmatic elements), as well as attributes of the individual graphic elements. Each attribute of a graphic element can include an attribute type and an attribute value. For an object, the types of attributes include, shape, dimension (or size), layer, type, color, line thickness, text size, text color, font, and/or other visual characteristics. Depending on implementation, the attributes reflect properties of two- or three-dimensional designs. In this way, attribute values of individual objects can define, for example, visual characteristics of size, color, positioning, layering, and content, for elements that are rendered as part of the UI design under edit 125.
[0046] According to examples, the IGDS 100 can execute variant component logic 108 to enable design users to create, modify and reuse variant components when working on the UI design under edit 125. … The IGDS 100 can in1plement the variant component logic 108 to define variant components to have constituent variants, with each variant being a design element (e.g., components) that is logically linked to other variants of the variant component. In particular, the variants of a variant component can share one or multiple predefined state properties, with each variant having a particular value for the state property or properties, such that each variant is unique amongst the variants of the variant component with respect to the state property values that are assigned to that variant. By way of example, the variant component can include a button, and each variant of the variant component defines a state of a run-time button feature. In such an example, the state property that may vary amongst the variants can be a fill pattern, and each variant of the variant component can be assigned to one of multiple possible property values (e.g., one of N fill patterns, where the run-time button feature is to have N states).).
The reasoning for combination of Ben-Aharon and Andersson is the same as described in Claim 1.
Regarding Claim 7. The combination of Ben-Aharon and Andersson further teaches The computer system of claim 1, wherein the value type of the variable data structure is a character string that represents a text attribute (Andersson, [0043] In examples, the rendering engine 120 uses the data structure representations 111 to render a corresponding UI design under edit 125 on the canvas 122, wherein the UI design under edit 125 reflects graphic elements and their respective attributes as provided with the individual pages of the files 101. The design user can edit the UI design under edit 125 using the design interface 118. Alternatively, the rendering engine 120 can generate a blank page for the canvas 122, and the design user can use the design interface 118 to generate the UI design under edit 125. As rendered, the UI design under edit 125 can include graphic elements such as a background and/or a set of objects (e.g., shapes, text, images, programmatic elements), as well as attributes of the individual graphic elements. Each attribute of a graphic element can include an attribute type and an attribute value. For an object, the types of attributes include, shape, dimension (or size), layer, type, color, line thickness, text size, text color, font, and/or other visual characteristics. Depending on implementation, the attributes reflect properties of two- or three-dimensional designs. In this way, attribute values of individual objects can define, for example, visual characteristics of size, color, positioning, layering, and content, for elements that are rendered as part of the UI design under edit 125.
Therefore, a font attribute is a character string such as “Arial”.).
The reasoning for combination of Ben-Aharon and Andersson is the same as described in Claim 1.
Regarding Claim 8. The combination of Ben-Aharon and Andersson further teaches The computer system of claim 1, wherein the value type of the variable data structure is a character string that represents a layer having a matching text content attribute (Andersson, [0043] … As rendered, the UI design under edit 125 can include graphic elements such as a background and/or a set of objects (e.g., shapes, text, images, programmatic elements), as well as attributes of the individual graphic elements. Each attribute of a graphic element can include an attribute type and an attribute value. For an object, the types of attributes include, shape, dimension (or size), layer, type, color, line thickness, text size, text color, font, and/or other visual characteristics. Depending on implementation, the attributes reflect properties of two- or three-dimensional designs. In this way, attribute values of individual objects can define, for example, visual characteristics of size, color, positioning, layering, and content, for elements that are rendered as part of the UI design under edit 125.
[0100] In examples, the IGDS 100 can implement a layer type naming scheme to identify the variant component 310 and its constituent variants 304, 306, 308. The naming scheme can structure a name for each constituent variant 304, 306, 308 to identify the state property and the state property value of that component. … As an addition or variation, the IGDS 100 can auto-generate the names of each variant 304, 306, 308 by determining the state property value of each of those components. For example, the design user can interact with the design tool panels 318 to specify the state property value of one or more constituent variants 304, 306, 308 of the variant component 310, and in turn, the IGDS 100 can auto-generate the name for each of those components using the naming scheme (e.g., "property/property value").
Further see Fig 3B.).
The reasoning for combination of Ben-Aharon and Andersson is the same as described in Claim 1.
Regarding Claim 9. The combination of Ben-Aharon and Andersson further teaches The computer system of claim 1, wherein a corresponding value of the variable data structure is defined at least in part by a logical expression and at least one of (i) an input of a user, and/or (ii) an attribute of another design element that is associated with the variable data structure (Andersson, [0045] The design interface 118 can process at least some user inputs to determine input information 127, where the input information 127 indicates (i) an input action type (e.g., shape selection, object selection, sizing input, color selection), (ii) an object that is directly indicated by the input action (e.g., object being resized), (iii) a desired attribute that is to be altered by the input action, and/or (iv) a desired value for the attribute being altered. The rendering engine 120 can receive the input information 127, and the rendering engine 120 can implement changes indicated by the input information 127 to update the UI design under edit 125. When changes are implemented to the UI design under edit 125, the changes can also be reflected in the accompanying data structure representations 111 for the UI design under edit 125.
[0052] As further described with some examples, the IGDS 100 can further implement the variant component logic 108 to enable additional variant component functionality. For example, as described with an example of FIG. 3E, variant components can be multi-dimensional, with each variant component being associated with multiple properties. For multi-dimensional variant components, the IGDS 100 can assign each variant to one combination of state property values, such that each combination of state property values is assigned to one variant and represents one of multiple possible states of the represented interactive object. Moreover, in examples, the IGDS 100 can enforce rules relating to how variant components are to be defined and used. For example, the IGDS 100 can enforce (i) a rule to assign only one variant of a variant component to a state property value of a single-dimension variant component, such that each state property value is assigned to only property value of the associated property; and (ii) a rule to assign only one variant to each combination of state property values for each of multiple properties associated with a multi-dimensional variant component, such that each combination of state property values for the associated state properties of the multi-dimensional property are assigned to only one variant. The IGDS 100 may generate error states, messages or prompts when such rules are violated by the designer.
Therefore, a rule to enforce only one variant to a state property value is a logical expression.).
The reasoning for combination of Ben-Aharon and Andersson is the same as described in Claim 1.
Regarding Claim 10. The combination of Ben-Aharon and Andersson further teaches The computer system of claim 1, wherein the operations further comprise: associating another design element of the graphic design with the variable data structure, and wherein a corresponding value of the variable data structure is based at least in part on an attribute of the associated design element (Andersson, [0094] As shown with FIG. 3B, the user can add additional design elements (represented by design element 308) to the variant component 310, by, for example, creating an instance off of another variant, then specifying a state property value that corresponds to one of the desired states for the interactive object. The IGDS 100 implements the variant component logic 108 to logically link the variants 304, 306, 308 as constituents of the variant component 310. In particular, the IGDS 100 can implement variant component logic 108 to (i) associate at least one property with the variant component 310, where the state property includes multiple possible property values; (ii) assign one of multiple possible state property values to each variant of the variant component, such that each variant has a unique state property value amongst all of the variants of the variant component; and (iii) specify a sequence and event type amongst the variants to define a state flow of the interactive object (see FIG. 5A and FIG. 5C). In this way, the user can define the state flow for an interactive object using design elements that are rendered at one time on the canvas 302.).
The reasoning for combination of Ben-Aharon and Andersson is the same as described in Claim 1.
Regarding Claim 11. The combination of Ben-Aharon and Andersson further teaches The computer system of claim 10, wherein the operations further comprise: in response to the attribute of the associated layer being modified by user input, updating the corresponding value of the variable data structure based on the modified attribute (Andersson, [0094] As shown with FIG. 3B, the user can add additional design elements (represented by design element 308) to the variant component 310, by, for example, creating an instance off of another variant, then specifying a state property value that corresponds to one of the desired states for the interactive object. The IGDS 100 implements the variant component logic 108 to logically link the variants 304, 306, 308 as constituents of the variant component 310. In particular, the IGDS 100 can implement variant component logic 108 to (i) associate at least one property with the variant component 310, where the state property includes multiple possible property values; (ii) assign one of multiple possible state property values to each variant of the variant component, such that each variant has a unique state property value amongst all of the variants of the variant component; and (iii) specify a sequence and event type amongst the variants to define a state flow of the interactive object (see FIG. 5A and FIG. 5C). In this way, the user can define the state flow for an interactive object using design elements that are rendered at one time on the canvas 302.
Therefore, user input can add multiple element to associate with variant component 310. Each element is assigned with its own unique attribute value.).
The reasoning for combination of Ben-Aharon and Andersson is the same as described in Claim 1.
Regarding Claim 12. The combination of Ben-Aharon and Andersson further teaches The computer system of claim 1, wherein the operations further comprise:
enabling a user to specify an interaction with the multi-state design element; and
in response to detecting the interaction with respect to the multi-state design element, updating or selecting the corresponding value of the variable data structure based on an attribute of the associated design element (Andersson, [0087] Further, the IGDS 100 enables the user to specify one or more interactions for the variant set (260). In examples, each interaction of the variant set is defined to specify a first variant (e.g., or initial or current variant) that is to change to a second variant (e.g., target or next variant) of the variant set. In such cases, each interaction that is defined for the variant set can have a respective first/second variants of the variant set, such that a variant set can have interactions with different first/second variants. In some examples, interactions may also be defined to be specific to a trigger event. For example, the user can specify individual interactions for a specific first/second variant of a variant set, and further in association with a specific type of event (e.g., run-time click or hover). As shown by FIG. 5A and FIG. 5C, in some examples, interactions can be visually rendered as noodles or line connectors that identify a sequence as between variants, where the sequence corresponds to a state flow for the represented run-time object (262). Further, the interactions can be associated on the canvas with an event type (e.g., trigger, input type) and other characteristics which further define the state flow for the interactive object.
[0126] Accordingly, each of the variants 516, 518 represent a state of a corresponding run-time object 536. The run-time object 536 can be executed (e.g., such as in a simulation or prototype environment) to exhibit a run-time behavior that is defined by the variants 516, 518 of the variant set 510, as well as the specified interactions 522, 524 of the variant set 510.).
The reasoning for combination of Ben-Aharon and Andersson is the same as described in Claim 1.
Regarding Claim 13. The combination of Ben-Aharon and Andersson further teaches The computer system of claim 12, wherein the operations further comprise:
enabling a simulation mode in which multiple states of the multi-state design element are sequentially renderable;
enabling the user to perform the interaction with respect to the associated
design element during the simulation mode; and
wherein updating or selecting the corresponding value of the variable data
structure is performed in response to the user performing the action (Andersson, [0087] Further, the IGDS 100 enables the user to specify one or more interactions for the variant set (260). In examples, each interaction of the variant set is defined to specify a first variant (e.g., or initial or current variant) that is to change to a second variant (e.g., target or next variant) of the variant set. In such cases, each interaction that is defined for the variant set can have a respective first/second variants of the variant set, such that a variant set can have interactions with different first/second variants. In some examples, interactions may also be defined to be specific to a trigger event. For example, the user can specify individual interactions for a specific first/second variant of a variant set, and further in association with a specific type of event (e.g., run-time click or hover). As shown by FIG. 5A and FIG. 5C, in some examples, interactions can be visually rendered as noodles or line connectors that identify a sequence as between variants, where the sequence corresponds to a state flow for the represented run-time object (262). Further, the interactions can be associated on the canvas with an event type (e.g., trigger, input type) and other characteristics which further define the state flow for the interactive object.
[0126] Accordingly, each of the variants 516, 518 represent a state of a corresponding run-time object 536. The run-time object 536 can be executed (e.g., such as in a simulation or prototype environment) to exhibit a run-time behavior that is defined by the variants 516, 518 of the variant set 510, as well as the specified interactions 522, 524 of the variant set 510.
[0127] Among other advantages, examples as described allow for the variants 516, 518 of the variant set 510 to be rendered at the same time, along with the interactions 522, 524, so that the states and state change behaviors of a run-time object are visually represented at the same time.).
The reasoning for combination of Ben-Aharon and Andersson is the same as described in Claim 1.
Claim 14 is similar in scope as Claim 1, and thus is rejected under same rationale.
Claim 15 is similar in scope as Claim 2, and thus is rejected under same rationale.
Claim 16 is similar in scope as Claim 3, and thus is rejected under same rationale.
Claim 17 is similar in scope as Claim 6, and thus is rejected under same rationale.
Claim 18 is similar in scope as Claim 9, and thus is rejected under same rationale.
Claim 19 is similar in scope as Claim 12, and thus is rejected under same rationale.
Claim 20 is similar in scope as Claim 1, and thus is rejected under same rationale. Claim 20 further requires:
A non-transitory computer-readable medium that stores instructions, that
when executed by one or more processors (Ben-Aharon, abstract, the invention describes a system implementable on a computing device having a processor and a memory, including a visual design system to generate a single visual data structure based on a hierarchy of components;).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to XIN SHENG whose telephone number is (571)272-5734. The examiner can normally be reached M-F 9:30AM-3:30PM 6:00PM-8:30PM.
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, Jason Chan can be reached at 5712723022. 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.
/Xin Sheng/Primary Examiner, Art Unit 2619
Prosecution Insights