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 .
DETAILED ACTION
This action is in response to the application filed on 05/12/2024.
Claims 1-20 are pending.
Examiner’s note
Please note that Examiner cites particular columns and line numbers in the references as applied to the claims below 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 entirely as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Specification
The disclosure is objected to because of the following informalities:
The use of the trademark/service mark “WiFi” and “Bluetooth” has been noted in this application (i.e., specification [0028]; applicants are respectfully requested to thoroughly check for any other trademark related issue). It should be appropriate or proper term (for example, Java™) (see MPEP 608.01(v)) used, wherever it appears and be accompanied by the generic terminology. Although the use of trademarks is permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as trademarks.
Appropriate correction is required.
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-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over USPN 20170083292 to McLaughlan et al. in view of USPN 20210019133 to Rusev et al.
Per claim 1:
McLaughlan discloses:
1. A script variable binding method, comprising:
defining a data property and a data source (Paragraph [0033,0038] “visual script 210 may include data representing a number of functions or methods that further include at least one input and at least one output… that defines a class that inherits functionality defined by the visual development environment 180 that includes an input name string, output name string, and input index”) of an input tag (Paragraph [0056] “a first graphical component indicating name Input and player ID”);
generating a logic script based on the input tag using a visual programming editing tool (Paragraph [0025] “visual editor may render graphical depictions of inputs, operations on the inputs, and outputs of the operations and/or depictions of a representation of the inputs, operations, and outputs… graphical depictions may be translated or scripted into corresponding instructions”);
when executing the logic script (Paragraph [0031] “access or execute a visual development environment 180 for launching or editing an application”), extracting a script input variable from a source data provided according to the data property and the data source of the input tag (Paragraph [0038] “visual script 210 may represent a desired operation such as retrieval (i.e., extracting) of a value from a key value store. The visual script may include a name of an input that represents the key and an output that represents the output value from the key value retrieval”);
when executing the logic script (Paragraph [0031] “access or execute a visual development environment 180 for launching or editing an application”), generating a script output variable based on a computational logic of the logic script and the script input variable corresponding to the input tag (Paragraph [0061-0062] “project components may represent a logical element… Project component 710 outputs the set parameter (i.e., variables) to project component 730 that further sets objects “string1” and “string 2.” Project component 740 receives the outputs from project component 730 to generate an access to the database services”); and
outputting the script output variable to a data destination (Paragraph [0031] “web browser may include code for generating some of the graphics for rendering data received from the service provider”).
The limitation regarding the script variable binding in the preamble is not given any patentable weight because the body of the claim does not recite any limitations related to the script variable binding.
McLaughlan does not explicitly disclose an Internet of Things (IoT) device.
However, Rusev discloses in an analogous computer system an Internet of Things (IoT) device (Fig. 1 elements 103, 106a-n and Paragraph [0014] “an internet of things (IoT) gateway 103, and a number of IoT endpoints 106a-n. The computing environment 101, the IoT gateway 103, and the IoT endpoints 106a-n can be in data communication with each other”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to incorporate the method of an Internet of Things (IoT) device as taught by Rusev into the method of a multi-tenant environment of developing and deploying software applications as taught by McLaughlan. The modification would be obvious because of one of ordinary skill in the art would be motivated to add/incorporate the features of an Internet of Things (IoT) device to provide an efficient technique of having IoT in a muti-tenant computing environment so as content can be created, constructed, programmed, and/or edited in a visual environment that does not require specific knowledge of programming languages as suggested by Rusev (paragraph [0016]).
Per claim 2:
The rejection of claim 1 is incorporated, the limitations the IoT device is taught by Rusev as explained above in related with claim 1 and further McLaughlan discloses:
2. The script variable binding method according to claim 1, wherein extracting the script input variable from the source data provided [[by the IoT device]] according to the data property and the data source of the input tag comprises:
extracting a first script input variable from a first source data belonging to a first data format according to the data property and data source of the input tag (Paragraph [0038] “retrieval of a value from a key value store… visual script may include a name of an input that represents the key and an output that represents the output value from the key value retrieval” also see paragraph [0056] which further describes having multiple inputs and ID); and
extracting a second script input variable from a second source data belonging to a second data format according to another data property and another data source of the input tag (Paragraph [0038] “visual script 210… including a text string indicating the key name variable… key value retrieval function with two ports”).
Per claim 3:
The rejection of claim 1 is incorporated, the limitations the IoT device is taught by Rusev as explained above in related with claim 1 and further McLaughlan discloses:
3. The script variable binding method according to claim 1, wherein the input tag comprises a first input tag and a second input tag, and extracting the script input variable from the source data provided by [[the IoT device]] according to the data property and the data source of the input tag comprises:
extracting a first script input variable from the source data according to a data property and a data source of the first input tag (Paragraph [0038] “retrieval of a value from a key value store… visual script may include a name of an input that represents the key and an output that represents the output value from the key value retrieval” also see paragraph [0056] which further describes having multiple inputs and ID); and
extracting a second script input variable from the source data according to a data property and a data source of the second input tag (Paragraph [0038] “visual script 210… including a text string indicating the key name variable… key value retrieval function with two ports” also see paragraph [0056] which further describes having multiple inputs and ID).
Per claim 4:
The rejection of claim 1 is incorporated, the limitations the IoT device is taught by Rusev as explained above in related with claim 1 and further McLaughlan discloses:
4. The script variable binding method according to claim 1, further comprising:
performing data formatting on the source data provided by [[the IoT device]] (Paragraph [0089] “data transformations to convert data signals from one component (e.g., system memory 1120) into a format suitable for use by another component (e.g., processor 1110)”).
Per claim 5:
McLaughlan discloses:
5. The script variable binding method according to claim 1, wherein defining the data property and the data source of the input tag comprises:
providing a tag setting interface (Paragraph [0034] “depicted user interface may allow for the visual script 210 to be edited”); and
determining the data property and the data source of the input tag (Paragraph [0038] “defines a class that inherits functionality defined by the visual development environment 180 that includes an input name string, output name string, and input index”) according to a user operation performed on the tag setting interface (Paragraph [0039] “Visual development environment 180 may include a rendering module 314 that is configured to interact with user interface components… be configured to present options on the user interface”).
Per claim 6:
McLaughlan discloses:
6. The script variable binding method according to claim 1, wherein generating the logic script based on the input tag using the visual programming editing tool comprises:
defining a data output property and an output destination of an output tag (Paragraph [0038] “defines a class that inherits functionality defined by the visual development environment 180 that includes an input name string, output name string, and input index”); and
generating the logic script based on the input tag and the output tag using the visual programming editing tool (Paragraph [0038] “generate a function that includes a call to a database service at the provider network, access to a database including a database identifier and value information, and returning of a value”).
Per claim 7:
McLaughlan discloses:
7. The script variable binding method according to claim 6, wherein outputting the script output variable to the data destination comprises:
outputting the script output variable to a local database or an online service according to the output destination and the data output property of the output tag (Paragraph [0031] “visual development environment 180 may further provide an interface for viewing the status of the request and modifying or cancelling the request… user interfaces that may be used for editing the application… user interface depictions may be generated by the service provider and sent to the user's display for rendering”).
Per claim 8:
McLaughlan discloses:
8. The script variable binding method according to claim 6, wherein generating the logic script based on the input tag and the output tag using the visual programming editing tool comprises:
recording the data property and the data source of the input tag in a configuration of a logical executor (Paragraph [0028] “operations to be applied to data based on changes detected in the storage and/or database services… server-side scripts and logic may be triggered based on new data being written to data storage, or based on monitoring specified data streams”); and
recording the data output property and the output destination of the output tag in a metadata of the logic script (Paragraph [0026] “a user may capture a screenshot or video pertaining to a game application and upload the data for sharing with others users… game data may be recorded and uploaded for other users to later download as challenges to the video game”).
Per claim 9:
McLaughlan discloses:
9. The script variable binding method according to claim 6, wherein defining the data output property and the output destination of the output tag comprises:
providing a tag setting interface (Paragraph [0034] “depicted user interface may allow for the visual script 210 to be edited”); and
determining the data output property and the output destination of the output tag (Paragraph [0038] “defines a class that inherits functionality defined by the visual development environment 180 that includes an input name string, output name string, and input index”) according to a user operation performed on the tag setting interface (Paragraph [0039] “Visual development environment 180 may include a rendering module 314 that is configured to interact with user interface components… be configured to present options on the user interface”).
Per claim 10:
McLaughlan discloses:
10. The script variable binding method according to claim 6, wherein the data output property of the output tag comprises a data storage path, a transmission protocol, service identification information of an online service, or a combination of the above (Since this appears to be MARKUSH type language requiring at a minimum just one from the list, McLaughlan teaches Paragraph [0061] “project components that may be used to access a database service at the provider network … project components may represent a logical element with a user-defined number of inputs and outputs”).
Claims 11-20 is/are the IoT gateway claim corresponding to method claims 1-10 respectively, and rejected under the same rational set forth in connection with the rejection of claims 1-10 respectively, as noted above. For claims 11, the limitation regarding the IoT gateway in the preamble is not given any patentable weight because the body of the claim does not recite any limitations related to the IoT gateway.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Related cited arts:
Al-Masri, Eyhab, et al. "Investigating messaging protocols for the Internet of Things (IoT)." IEEE Access 8 (2020): pp. 94880-94911.
Oktian, Yustus Eko, and Sang-Gon Lee. "BorderChain: Blockchain-based access control framework for the Internet of Things endpoint." IEEE Access 9 (2020): pp. 3592-3615.
Nugur, Aditya. Design and Development of an Internet-Of-Things (IoT) Gateway for Smart Building Applications. Diss. Virginia Tech, 2017. pp. 9020-9029.
US10552125 - A method for delivering a message between components in a project using a GUI through which users may be able to monitor and control industrial processes. Each component has graphical features and/or behavioral features. The method comprises steps of: receiving first definition input to define a message handler associated with a first component in the project for receiving messages for the first component and receiving second definition input to define a messenger associated with a second component in the project for sending messages. The method includes, in response to receiving a payload input via the messenger associated with the second component: identifying components having associated message handlers with a message type definition that matches a message type argument of the messenger and a scope definition that matches a scope argument of the messenger, delivering the payload, and executing script implementations of the message handlers.
US10846063 - A method provides a synchronization cycle for updating changing component property values at a client and a gateway system. When the client receives a change to a value, it saves the change as a pending value in association with an existing value for the component property. The client sends a set of changes and an identifier to the gateway system. The gateway system updates its component property values accordingly. The gateway system accumulates changes to property values including changes from the client and other changes received via data bindings or other methods. The gateway system sends a message to the client including the accumulated property value changes and the identifiers associated with client-provided value changes that have been applied. The client updates its component property values according to the accumulated changes and removes references to pending values that are associated with identifiers sent back by the gateway system.
US11656603 - An industrial gateway device supports interactive feature engineering tools that guide a user through an intuitive process for configuring data analytics for key performance indicators (KPIs) of interest. A feature engineering interface renders an interactive model view that displays available data points such that the data points are organized hierarchically according to plant, machine, machine property, or other elements. The user can select, from this model view, data points having an impact on the KPI of interest. The interface also allows the user to define an executable script that defines a mathematical relationship between the selected data points and the KPI. This configuration yields an output model that defines a reduced set of data points to be collected and analyzed, as well as an executable script for assessing a state of the KPI as a function of the reduced data point values.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Satish Rampuria whose telephone number is 571-272-3732. The examiner can normally be reached on Monday-Friday from 8:30 AM to 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do, can be reached at telephone number 571-272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
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.
/Satish Rampuria/Primary Examiner, Art Unit 2193
*****
Prosecution Insights