Y Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
DETAILED ACTION
This action is in response to application filed 05/20/2026.
Claims 1-5, 8, 10-16, 19-20 are pending in this application.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 12, and 20 in view of amended limitation (“…sending, by a first interface among a plurality of first interfaces comprised in the agent module, the second message to the framework module according to a second identity added in the second message for the framework module to forward the second message to the first UI module…”) have been considered but are moot because the new ground of rejection. Upon further consideration, a new ground(s) of rejection is made over Anderson et al. (US 2019/0189084 A1) in view of Yuan et al. (CN 111158818 B) in further view of Kamepalli et al. (US 2021/0294556 A1).
Claim Objections
Claims 1, 12, and 20 are objected because they lack clarity. The claims recite a “first message”, and a “second message”, and subsequently recite a “fourth message” without reciting a “third message”. Although the specification describes both a third message (see specification [0073]-[0074]) and a fourth message (see specification [0087]-[0088]) as distinct messages, omission of a third message from the claim results in inconsistent message numbering. Appropriate correction is required while maintaining consistency with the specification
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 4, 10-12, 15, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Anderson et al. (US 2019/0189084 A1) in view of Yuan et al. (CN 111158818 B) in further view of Kamepalli et al. (US 2021/0294556 A1).
Regarding claim 1, Anderson discloses an intra-device communication method, comprising: receiving, by an agent module of a first device having a display screen, a to-be-forwarded message (fig. 4, [0052]: the display function driver 402, which may correspond to display stack 114 (e.g. agent module) , can receive (e.g., via a display level service 112) an incoming request (e.g. to-be forwarded message) to set a nits-based brightness level for a display device)
in response to the to-be-forwarded message being a first message forwarded by a framework module of the first device ([0021], [0052]: display level service 112 (e.g. framework module) can specify a nits-based brightness level via display stack 114 (e.g. agent). The display function driver 402, which may correspond to display stack 114 (e.g. agent module) receive via a display level service 112 (e.g. framework module) an incoming request (e.g. to-be-forwarded message) sending, by the agent module, the first message to a corresponding function module related to screen brightness [0052]: Display function driver 402 (e.g. agent) can send an input/output control (IOCTL) request packet (IRP) (e.g. first message) to the panel driver 404 of the corresponding display device (e.g. corresponding function module)to indicate the nits-based brightness level adjustment. The panel driver 404 can similarly send an IOCTL IRP to the graphics kernel 408. Graphics kernel 408 can convert the IOCTL IRP indicating the nits-based brightness level to a device driver interface (DDI) call to the hardware kernel mode driver 410), wherein the framework module is connected with a plurality of user interface (UI) modules of the first device ([0002], [0020], [0046]: input from a user interface, or input from an application executing on the operating system (e.g. UI modules executing on the OS), allow for adjustment of the brightness level. The one or more applications, services, etc. executing on the operating system 106 (e.g. plurality of UI modules) may include a display level service 112 (e.g. framework) for specifying one or more display parameter levels (e.g., brightness level) or other display properties to a display stack 114. The display level service 112 (framework) may communicate the instruction in a message to the display stack 114 (agent), the first message is sent from a first UI module among the plurality of UI modules and used to request to adjust a brightness of the display screen to a first brightness ([0020], [0033]-[0034]: one of the selectable brightness levels, selected via the operating system, can be determined. In an example, display level selecting component 118, e.g., in conjunction with processor 102 can determine the one of the selectable brightness levels as being selected via the operating system 106. For example, display level selecting component 118 can receive an indication of the selected brightness level from the operating system 106 based on a manual selection via a user interface (e.g. UI module requesting brightness adjustment), and the agent module is connected with a plurality of function modules of the first device ([0051]: adjusting display level parameters of a display device. Operating system components can include a display function driver 402 (e.g. agent) that can provide a generic display interface for managing communications with different panel drivers 404 (e.g. agent connected to multiple function module) an advanced configuration and power interface (ACPI) driver 406 for managing power control of power consumed by the operating system, a graphics kernel 408 for providing commands (e.g., drawing or other display setting commands) to a hardware kernel mode driver 410 that communicates with a corresponding display device), different UI modules are configured to implement different UI functions ([0020], [0033]-[0034]: The one or more applications, services, etc. executing on the operating system 106 (e.g. UI modules) may include a display level service 112 for specifying one or more display parameter levels (e.g., brightness level, color level, etc.) or other display properties (e.g. UI functions), the framework module is an application framework installed in the first device ([0020]: The one or more applications, services, etc. executing on the operating system 106 may include a display level service 112 (i.e. display level service 112 is an application framework). [0055]: Device 500 may further include memory 504 for storing local versions of applications being executed by processor 502, such as display level service 112 (e.g. framework), an operating system (or other components thereof), applications, related instructions, parameters, etc. (i.e. framework installed in device), and the agent module is a program module installed in the first device ([0055],[0055]: Operating system components 400 (e.g., provided by an operating system, such as operating system 106) can include a display function driver 402 (e.g. agent) that can provide a generic display interface for managing communications with different panel drivers 404), at least one of the function modules is a hardware module involving an underlying layer ([0051]-[0052]: Display function driver 402 (e.g. agent) can send an input/output control (IOCTL) request packet (IRP) to the panel driver 404 of the corresponding display device (e.g. function module) to indicate the nits-based brightness level adjustment. The panel driver 404 can similarly send an IOCTL IRP to the graphics kernel 408. The hardware kernel mode driver 410 (e.g. underlying layer) can instruct the display device 412 (e.g. function module is a hardware) to modify the brightness level to the nits-based brightness level adjustment and/or can perform a query to the display device 412) and the framework module and the function modules are located at different layers (fig. 1,fig. 4, [0051]-[0053]: the display function driver 402, which may correspond to display stack 114 (e.g. agent module) can receive via a display level service 112 (e.g. framework execution on operating system) an incoming request to set a nits-based brightness level for a display device (e.g. function modules located in different layer (see fig. 4);
in response to the to-be-forwarded message being a second message from the corresponding function module related to screen brightness, wherein the second message is used to indicate an adjust result of brightness of the display screen (fig. 4, [0053]: where the panel driver 404 sends the IOCTL IRP to the graphics kernel 408, when the hardware kernel mode driver 410 operations to set the nits-based brightness level are complete, the hardware kernel mode driver 410 can perform a DDI callback up (e.g. second message) to the graphics kernel 408. The graphics kernel 408 can convert the DDI callback to an IOCTL IRP, and can block the DDI thread until the IRP completes or returns to the hardware kernel mode driver 410. The graphics kernel 408 can forward the IOCTL IRP to the display function driver 402 (agent) to release the IRP. Note: Anderson discloses sending a callback up message (e.g. second message) after the completion of the requested brightness setting operation. The callback up message is sent to the display function driver (agent) from the hardware kernel mode driver in response of brightness adjustment from part of a display device).
However, Anderson does not disclose sending, by a first interface among a plurality of first interfaces comprised in the agent module, the second message to the framework module according to a second identity added in the second message for the framework module to forward the second message to the first UI module.
In an analogous art, Yuan discloses sending, by a first interface among a plurality of first interfaces comprised in the agent module, the second message to the framework module according to a second identity added in the second message for the framework module to forward the second message to the first UI module (pg. 4, [0001]: SDK function module returns the execution results (e.g. second message) to the component, which is received by the component through the callback of the rendering engine (e.g. framework module) to the micro application function (e.g. UI module). Pg. 5, [0005]: all communication between native component libraries and JavaScript is completed in the framework through BridgeMode (e.g. agent). The bridge triggers the native container and then distributes the plugin-action to specific components, Pg. 7, [0010]-[0013]: after the native component library (e.g. bridge) calls the corresponding type of interface (e.g. first interface from different interfaces) according to the incoming parameters…Call the exec.js module to generate a unique callbackId parameter (second identity), so that the corresponding component can call back the execution result to the callback receiving function (e.g. UI module) of the micro application through the rendering engine (framework) and call back execution results to the corresponding function of micro application (first UI). Note: Yuan discloses a call back message (e.g. second message). A native component library operating with a bridge communication (agent module) calls the corresponding interface (e.g. an interface among many) according to the receiving parameters. Using a CallbackContext and sendPluginResult (first interface/mechanism) find the corresponding callbackID (e.g. second identity). The result is then called back through the rendering engine (e.g. framework module) to the corresponding JavaScript caller/callback receiving function of the micro application (first UI). Anderson discloses after the completion of the requested brightness setting operation, a callback message is sent)
Therefore, it would have been obvious before the effective filed date of the claimed invention to a person having ordinary skill in the art to modify Anderson to comprise “sending, by a first interface among a plurality of first interfaces comprised in the agent module, the second message to the framework module according to a second identity added in the second message for the framework module to forward the second message to the first UI module” taught by Yuan
One of ordinary skill in the art would have been motivated because it would have enabled using a callback mechanism to associate a returned execution result with the corresponding requesting application and route the result through the rendering engine to the appropriate application callback using a unique callback ID (Yuan, pg. 7, [0010]-[0013]).
However, Anderson-Yuan does not disclose wherein the corresponding function module related to screen brightness sends a fourth message to a second device connected with the first device, wherein the fourth message is configured for the second device to record a current brightness of the display screen of the first device.
In an analogous art, Kamepalli discloses wherein the corresponding function module related to screen brightness ([0031], [0040]: user may interact with a display device 122 to indicate a desire to modify setting (e.g., brightness), and/or other characteristic of display device. MCU 123 may monitor for user modification of display settings occurring at the first display device 122 associated with MCU 123 (e.g., function module). If user modification of display settings occurs local to the first display device 122), sends a fourth message to a second device connected with the first device, wherein the fourth message is configured for the second device to record a current brightness of the display screen of the first device ([0031]-[0033]: multiple display devices 122 (second device) may be configured to synchronize (record) display settings among themselves in response to a user modifying settings on one of the multiple display devices 122. [0041]: responsive to user interaction with user interface 138 to modify display settings, MCU 123 may communicate a vendor-defined message (e.g. fourth message) via USB PD interface 134 to management controller 112 indicating user modification of display settings at the display device. [0051]: management controller 112 may communicate the display settings change by broadcasting a vendor-defined message via USB PD interface 114 to MCUs 123 of one or more display devices 122 (e.g. second device) other than the first display device 122 indicating a user modification of display settings of the first display device 122. [0039]: in response to receipt of a vendor-defined message (e.g. fourth message) from information handling system 102 indicating user modification of display settings on another display device 122 (e.g. first device), MCU 123 may cause a corresponding change to the first display device 122 (second device) as if its own user interface 138 had received user interaction to modify such display settings).
Therefore, it would have been obvious before the effective filed date of the claimed invention to a person having ordinary skill in the art to modify Anderson-Yuan to comprise “wherein the corresponding function module related to screen brightness sends a fourth message to a second device connected with the first device, wherein the fourth message is configured for the second device to record a current brightness of the display screen of the first device” taught by Kamepalli.
One of ordinary skill in the art would have been motivated because it would have enabled to synchronize and maintain consistent brightness setting among connected display devices by communicating brightness setting modifications between the devices (Kamepalli, [0033]).
Regarding claim 4, Anderson-Yuan-Kamepalli discloses the method according to claim 1, wherein sending the first message to the corresponding function module comprises: obtaining a first identity in the first message; and based on the first identity, sending the first message to the corresponding function module identified by the first identity (Yuan, pg. 5, [0006]: a call mapping plugin-action is generated (first identity). The bridge accesses the top layer of the container according to the existing plugin mapping. The top layer of the container is distributed to the specific container according to the incoming parameters. After the execution is completed, the data is called back to the micro application). The same rationale applies as in claim 1.
Regarding claim 10, Anderson-Yuan-Kamepalli discloses the method according to claim 1, wherein the agent module is an agent service process installed in the first device (Anderson, fig. 1, [0051]-[0052]: Operating system components 400 (e.g., provided by an operating system, such as operating system 106) can include a display function driver 402 that can provide a generic display interface for managing communications with different panel drivers 404. The display function driver 402, which may correspond to display stack 114 (e.g. agent service process), can receive via a display level service 112 an incoming request to set a nits-based brightness level for a display device).
Regarding claim 11, Anderson-Yuan-Kamepalli discloses the method according to claim 1, wherein the framework module is a quick application framework installed in the first device (Yuan, pg. 5, [0003]: a micro-application SDK according to an embodiment of the present invention. The micro-application SDK framework includes a micro-application, an HTML rendering engine and a component library). The same rationale applies as in claim 1.
Regarding claims 12 and 20; the claims are interpreted and rejected for the same reason as set forth in claim 1.
Regarding claim 15; the claim is interpreted and rejected for the same reason as set forth in claim 4.
Claims 2-3, 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Anderson in view of Yuan in view of Kamepalli, as applied to claim 1, in further view of Conner et al. (US 2008/0140759 A1).
Regarding claim 2, Anderson-Yuan-Kamepalli discloses the method according to claim 1.
However, Anderson-Yuan-Kamepalli does not disclose wherein sending the first message to the corresponding function module comprises: in response to the first message being in a first format, converting the first message in the first format into a second format and sending the first message to the corresponding function module, wherein the first format is a data format recognizable by the framework module, and the second format is a data format recognizable by the corresponding function module.
In an analogous art, Conner discloses wherein sending the first message to the corresponding function module comprises: in response to the first message being in a first format, converting the first message in the first format into a second format and sending the first message to the corresponding function module, wherein the first format is a data format recognizable by the framework module, and the second format is a data format recognizable by the function module ([0095]: data is transferred between a service requester core logic component 56 and service provider core logic component 60 (e.g. function module) read data transfer request is initially issued by a service requester core logic component 56 as a business method call through 244 the service interface stub 78. The service requester invocation framework component 80 (e.g. framework) may perform 248 method name, parameter, and return value mapping, conversion and translation operations to functionally adapt the business method call to the business operation interface requirements of the intended service provider 54 (first format receive by framework transform to second format recognize by service provider core logic component). Fig. 3, [0096]-[0097]: In response, the service proxy class 82 (e.g. agent), directs the issuance 252 of the data transfer request as a business operation call, in the form of a web services, J2EE, JMS, REST, other request, specific to the service invocation interface 62 of the intended service provider 54 (e.g. service provider core logic component 60).
Therefore, it would have been obvious before the effective filed date of the claimed invention to a person having ordinary skill in the art to modify Anderson-Yuan-Kamepalli to comprise “wherein sending the first message to the corresponding function module comprises: in response to the first message being in a first format, converting the first message in the first format into a second format and sending the first message to the corresponding function module, wherein the first format is a data format recognizable by the framework module, and the second format is a data format recognizable by the function module” taught by Conner.
One of ordinary skill in the art would have been motivated because it would have enabled messages communicated between the framework component and the corresponding service provider core logic component to be converted into a format compatible with the receiving component, thereby facilitating interoperable communication between component having different data format and interface requirements (Conner, [0095]).
Regarding claim 3, Anderson-Yuan-Kamepalli-Conner discloses the method according to claim 2, wherein sending the second message to the framework module comprises: in response to the second message being in the second format, converting the second message into the first format and sending the second message to the framework module (Conner, [0098]: As processed by and through the service provider core logic component 60, the data transfer request may return a new DTO or updated parameter DTO. In the preferred embodiments of the present invention, a data request response (e.g. second message) as typically coupled with DTO is processed through the application server 72 with the result that the DTO is returned 254 to the service proxy class 82 (e.g. agent). The service proxy class 82 perform reverse mapping, conversion and translation operations defined by the service proxy class 82 (e.g. converting from second format to first format). The DTO is then returned 256 to the service requester invocation framework component 80 (framework) where any reverse mapping, conversion, and translation operations defined by the SIM meta-data 114 are then performed 258. The DTO is further returned 260 to the service interface stub 78. Finally, an ordinary call return 262 delivers the DTO to the service requester core logic component 56.). The same rationale applies as in claim 2.
Regarding claim 13; the claim is interpreted and rejected for the same reason as set forth in claim 2.
Regarding claim 14; the claim is interpreted and rejected for the same reason as set forth in claim 3.
Claims 5 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Anderson in view of Yuan in view of Kamepalli, as applied to claim 1, in further view of Friedman et al. (US 2004/0163037 A1).
Regarding claim 5, Anderson-Yuan-Kamepalli discloses the method according to claim 1.
However, Anderson-Yuan-Kamepalli does not disclose further comprising: performing a message transmission between the agent module and the framework module using a first communication protocol; and performing a message transmission between the agent module and the corresponding function module using a second communication protocol, wherein the first communication protocol supports a communication between processes running on a same kernel, and the second communication protocol supports a communication between processes running on different kernels.
In an analogous art, Friedman discloses performing a message transmission between the agent module and the framework module using a first communication protocol ([0060]: operational block 301 bridge 106 receives a request that is in a non-WebDAV protocol (e.g., FTP request 20 in FIG. 2) that is not natively capable of invoking a WebDAV method); and performing a message transmission between the agent module and the corresponding function module using a second communication protocol ([0060]: the input handler translates the request from the non-WebDAV protocol to a canonical format. In sub-block 34, the canonical formatted request is processed to construct a WebDAV protocol request… WebDAV protocol request is used to invoke the desired WebDAV method), wherein the first communication protocol supports a communication between processes running on a same kernel, and the second communication protocol supports a communication between processes running on different kernels ([0028]: bridge 106, which is shown in this example as being implemented within server 105 but may in other embodiments be arranged external to server 105 and communicatively coupled thereto. As shown, bridge 106 is communicatively coupled to WebDAV method processing unit 108 via communication link 107).
Therefore, it would have been obvious before the effective filed date of the claimed invention to a person having ordinary skill in the art to modify Anderson-Yuan-Kamepalli to comprise “further comprising: performing a message transmission between the agent module and the framework module using a first communication protocol; and performing a message transmission between the agent module and the corresponding function module using a second communication protocol, wherein the first communication protocol supports a communication between processes running on a same kernel, and the second communication protocol supports a communication between processes running on different kernels” taught by Friedman.
One of ordinary skill in the art would have been motivated because it would have enabled to translate a received request from any of a plurality of different protocols to a canonical format (Friedman, [0010]).
Regarding claim 16; the claim is interpreted and rejected for the same reason as set forth in claim 5.
Claims 8 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Anderson in view of Yuan in view of Kamepalli, as applied to claim 1, view of Zhao (US 2013/0191526 A1).
Regarding claim 8, Anderson-Yuan-Kamepalli discloses the method according to claim 1.
However, Anderson-Yuan-Kamepalli does not disclose wherein the first message comprises a message generated by the UI module detecting a starting operation that triggers any UI function.
In an analogous art, Zhao wherein the first message comprises a message generated by the UI module detecting a starting operation that triggers any UI function ([0052]: the management of the plug-in may further include: the browser inquires whether plug-in version information needs to be updated via the plug-in management platform when the browser is launched).
Therefore, it would have been obvious before the effective filed date of the claimed invention to a person having ordinary skill in the art to modify Anderson-Yuan-Kamepalli to comprise “wherein the first message comprises a message generated by the UI module detecting a starting operation that triggers any UI function” taught by Zhao.
One of ordinary skill in the art would have been motivated because it would have enabled to provide an interacting medium of a plug-in with the browser in order to manage the plug-in, and then to adapt the plug-in for invoking by the browser (Zhao, [0006]).
Regarding claim 19; the claim is interpreted and rejected for the same reason as set forth in claim 8.
Additional References
The prior art made of record and not relied upon is considered pertinent to applicants’ disclosure.
Boskovic, US 2013/0159379 A1: App System Platform.
Thompson, US 2018/0309819 A1: Endpoint Management System Providing an Application Programing Interface Proxy Service.
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 JUAN C TURRIATE GASTULO whose telephone number is (571)272-6707. The examiner can normally be reached Monday - Friday 8 am-4 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, Glenton B Burgess can be reached at (571)272-3949. 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.
/J.C.T/Examiner, Art Unit 2454
/GLENTON B BURGESS/Supervisory Patent Examiner, Art Unit 2454
Prosecution Insights