DETAILED ACTION
Applicant’s amendment and arguments filed July 31, 2026 is acknowledged.
Claims 1, 5, and 8 have been amended.
Claims 4, 11, and 18 are cancelled.
Claims 1-3, 5-10, 12-17, 19, and 20 are currently pending.
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 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 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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
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, 5, 8, 12, 15, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Maddox et al. (hereinafter Maddox) (U.S. Patent Application Publication # 2022/0166563 A1) in view of Gidron et al. (hereinafter Gidron) (U.S. Patent Application Publication # 2015/0019620 A1), and further in view of Ewing et al. (hereinafter Ewing) (U.S. Patent # 9,503,974 B1).
Regarding claims 1 and 8, Maddox teaches and discloses a network connection method, wherein the method is applied to a first electronic device (110, figure 1) and first electronic device (110, figure 1), wherein the first electronic device comprises a processor (processor, 112, figure 1), a memory (memory, 114, figure 1), and a program or an instruction stored in the memory and executable on the processor, and the program or the instruction ([0013]), when executed by the processor, causes the first electronic device to perform:
when a remote networking condition is met ([0011]; “…a BLE-enabled device 110 and a BLE-enabled device 150 that may need to communicate data or procedure calls in one or both directions between devices…”; a remote condition, such as a BLE-enabled device connected to another BLE-enabled device which needs to communicate or procedure call),
sending a remote procedure call (RPC) operation request ([0010]; “…One or more of the layers may support Remote Procedure Calls (RPCs) to allow procedures or functions on either of two paired devices to be executed on one device on behalf of the other device…”; [0043]; “...messages may have a type indicating a remote procedure call. To enable Remote Procedure Call (RPC) functionality, the master/client device (e.g., a phone) and slave/server device (e.g., a sensor system) may use a JSON formatted data package…to state the function or procedure to be called and the parameters for the function or procedure being called; teaches sending a RPC operation request);
a second electronic device (150, figure 1) generates an RPC operation response, and sends the RPC operation response to the first electronic device; receiving the RPC operation response sent by the second electronic device ([0010]; “…One or more of the layers may support Remote Procedure Calls (RPCs) to allow procedures or functions on either of two paired devices to be executed on one device on behalf of the other device…”; [0043]; “...messages may have a type indicating a remote procedure call. To enable Remote Procedure Call (RPC) functionality, the master/client device (e.g., a phone) and slave/server device (e.g., a sensor system) may use a JSON formatted data package…to state the function or procedure to be called and the parameters for the function or procedure being called. The return value of the function and the success status of the call may be returned in a set format so that the caller can connect the correct code with the results…A response message to a function call may contain…”; [0044]; “…“return”:{“function”:“ScanNetworks”,
“return”: [“SSID_01”,“SSID_02”]}} where “return” is a key indicating the message is returned from a function call and the values “SSID_01” and “SSID_02” being returned, “function” is a key for identifying the function “ScanNetworks.”…”; teaches the first device sending a RPC operation request to the second device and the second device sending/returning a RPC response back to the first device based the RPC operation request); wherein the remote networking condition comprises: the first electronic device is connected to the second electronic device ([0011]; "...a BLE-enabled device 110 and a BLE-enabled device 150 that may need to communicate data or procedure calls in one or both directions between devices..."; a remote condition, such as a BLE-enabled device connected to another BLE-enabled device which needs to communicate or procedure call).
However, Maddox may not explicitly disclose sending a RPC operation request comprising a network interface function call number to a second electronic device, so that the second electronic device calls a network interface call function indicated by the network interface function call number, generates an RPC operation response according to response information of a network interface called by the network interface call function; and parsing the RPC operation response to obtain the response information of the network interface.
Nonetheless, in the same field of endeavor, Gidron teaches and suggests sending a RPC operation request (RPC request; figure 3; abstract) comprising a network interface function call number (ID of the RPC call; [0005]) to a second electronic device (server-side, figures 1 and 3), so that the second electronic device calls a network interface call function (call context; [0018]; function call; [0043]) indicated by the network interface function call number (ID of the RPC call; [0005]) ([0005]; “…generating an RPC request which corresponds to an RPC call, the RPC request is addressed to an RPC server side and the RPC request includes an RPC call ID…”; [0018]; [0043]; [0061]; teaches a client side device sending an RPC request, wherein the request comprises an ID of the RPC call to a second, server-side device), generates an RPC operation response (RPC reply; figure 3; abstract) according to response information of a network interface called by the network interface call function ([0005]; [0018]; “…generate a respective RPC reply that is addressed to the RPC client side and the RPC reply includes the ID of the RPC call and a server context ID which is uniquely associated, on the RPC server side, with the transaction which the RPC call is part of…”; [0066]; [0067]; teaches the second, server-side device generates and sends an RPC reply in response to the information in the RPC request); and parsing the RPC operation response to obtain the response information of the network interface ([0005]; [0018]; “…Responsive to receiving the RPC reply, the RPC client side can be configured to: log the RPC reply and the server context ID in the entry that includes the ID of the RPC call…”; [0066]; [0067]; teaches the client-side device receives and parses the RPC response sent by the second, server-side device to obtain the response information).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a client side device sending an RPC request, wherein the request comprises an ID of the RPC call to a second, server-side device and teaches the client-side device receives and parses the RPC response sent by the second, server-side device to obtain the response information as taught by Gidron with the method and apparatus for the first device sending a RPC request to the second device and the second device sending a RPC response back to the first device as disclosed by Maddox for the purpose of providing redundancy in highly available communication of remote procedure calls, as suggested by Gidron.
However, Maddox, as modified by Gidron, may not explicitly disclose wherein the remote networking condition comprises: power consumption of the first electronic device is greater than a specified power consumption threshold; or electrical energy of the first electronic device is less than a specified electrical energy threshold.
Nonetheless, in the same field of endeavor, Ewing teaches and suggests wherein the remote networking condition comprises: power consumption of the first electronic device is greater than a specified power consumption threshold; or electrical energy of the first electronic device is less than a specified electrical energy threshold (column 8, lines 50-57; “…it is possible for any node 21-24 to use a remote procedure call to invoke a function stored on any of the other nodes of the network 20. As used herein a “remote” procedure call refers to any procedure call that is communicated from one node to another such that the procedure call is executed on a node that is remote from the one that originally transmitted the procedure call…”; column 19, lines 40-60; “…the communication device 77 (FIG. 2) of each node 21-24 is configured to provide a signal, referred to hereafter as “energy level signal,” indicative of the amount of energy detected for the channel being used by the node for network communication. Before wirelessly transmitting a message via the same channel, the node's stack 54 analyzes the energy level signal…determines that the energy level signal is below the threshold. When this occurs, the stack 54 proceeds with transmitting the message by sending the message to the communication device 77 for wireless transmission…”; column 20, lines 4-8 and 44-50; teaches the networking condition includes an energy level is less than a threshold).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the networking condition includes an energy level is less than a threshold as taught by Ewing with the method and apparatus for the first device sending a RPC request to the second device and the second device sending a RPC response back to the first device as disclosed by Maddox, as modified by Gidron, for the purpose of reducing data collision, as suggested by Ewing.
Regarding claim 5, Maddox teaches and discloses a network connection method, wherein the method is applied to a second electronic device (150, figure 1) and comprises: receiving a remote procedure call (RPC) operation request that is sent by a first electronic device (110, figure 1) ([0010]; “…One or more of the layers may support Remote Procedure Calls (RPCs) to allow procedures or functions on either of two paired devices to be executed on one device on behalf of the other device…”; [0043]; “...messages may have a type indicating a remote procedure call. To enable Remote Procedure Call (RPC) functionality, the master/client device (e.g., a phone) and slave/server device (e.g., a sensor system) may use a JSON formatted data package…to state the function or procedure to be called and the parameters for the function or procedure being called; teaches sending a RPC operation request);
generating an RPC operation response according to response information; and sending the RPC operation response to the first electronic device ([0010]; “…One or more of the layers may support Remote Procedure Calls (RPCs) to allow procedures or functions on either of two paired devices to be executed on one device on behalf of the other device…”; [0043]; “...messages may have a type indicating a remote procedure call. To enable Remote Procedure Call (RPC) functionality, the master/client device (e.g., a phone) and slave/server device (e.g., a sensor system) may use a JSON formatted data package…to state the function or procedure to be called and the parameters for the function or procedure being called. The return value of the function and the success status of the call may be returned in a set format so that the caller can connect the correct code with the results…A response message to a function call may contain…”; [0044]; “…“return”:{“function”:“ScanNetworks”,“return”: [“SSID_01”,“SSID_02”]}} where “return” is a key indicating the message is returned from a function call and the values “SSID_01” and “SSID_02” being returned, “function” is a key for identifying the function “ScanNetworks.”…”; teaches the first device sending a RPC request to the second device and the second device sending/returning a RPC response back to the first device); wherein the remote networking condition comprises: the first electronic device is connected to the second electronic device ([0011]; "...a BLE-enabled device 110 and a BLE-enabled device 150 that may need to communicate data or procedure calls in one or both directions between devices..."; a remote condition, such as a BLE-enabled device connected to another BLE-enabled device which needs to communicate or procedure call).
However, Maddox may not explicitly disclose receiving a remote procedure call (RPC) operation request that comprises a network interface function call number; calling a network interface call function indicated by the network interface function call number; generating an RPC operation response according to response information of a network interface called by the network interface call function.
Nonetheless, in the same field of endeavor, Gidron teaches and suggests receiving a remote procedure call (RPC) operation request (RPC request; figure 3; abstract) that comprises a network interface function call number (ID of the RPC call; [0005]); calling a network interface call function (call context; [0018]; function call; [0043]) indicated by the network interface function call number ([0005]; “…generating an RPC request which corresponds to an RPC call, the RPC request is addressed to an RPC server side and the RPC request includes an RPC call ID…”; [0018]; [0043]; [0061]; teaches a client side device sending an RPC request, wherein the request comprises an ID of the RPC call to a second, server-side device); generating an RPC operation response (RPC reply; figure 3; abstract) according to response information of a network interface called by the network interface call function ([0005]; [0018]; “…generate a respective RPC reply that is addressed to the RPC client side and the RPC reply includes the ID of the RPC call and a server context ID which is uniquely associated, on the RPC server side, with the transaction which the RPC call is part of…”; [0066]; [0067]; teaches the second, server-side device generates and sends an RPC reply in response to the information in the RPC request).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a client side device sending an RPC request, wherein the request comprises an ID of the RPC call to a second, server-side device and teaches the client-side device receives and parses the RPC response sent by the second, server-side device to obtain the response information as taught by Gidron with the method and apparatus for the first device sending a RPC request to the second device and the second device sending a RPC response back to the first device as disclosed by Maddox for the purpose of providing redundancy in highly available communication of remote procedure calls, as suggested by Gidron.
However, Maddox, as modified by Gidron, may not explicitly disclose wherein the remote networking condition comprises: power consumption of the first electronic device is greater than a specified power consumption threshold; or electrical energy of the first electronic device is less than a specified electrical energy threshold.
Nonetheless, in the same field of endeavor, Ewing teaches and suggests wherein the remote networking condition comprises: power consumption of the first electronic device is greater than a specified power consumption threshold; or electrical energy of the first electronic device is less than a specified electrical energy threshold (column 8, lines 50-57; “…it is possible for any node 21-24 to use a remote procedure call to invoke a function stored on any of the other nodes of the network 20. As used herein a “remote” procedure call refers to any procedure call that is communicated from one node to another such that the procedure call is executed on a node that is remote from the one that originally transmitted the procedure call…”; column 19, lines 40-60; “…the communication device 77 (FIG. 2) of each node 21-24 is configured to provide a signal, referred to hereafter as “energy level signal,” indicative of the amount of energy detected for the channel being used by the node for network communication. Before wirelessly transmitting a message via the same channel, the node's stack 54 analyzes the energy level signal…determines that the energy level signal is below the threshold. When this occurs, the stack 54 proceeds with transmitting the message by sending the message to the communication device 77 for wireless transmission…”; column 20, lines 4-8 and 44-50; teaches the networking condition includes an energy level is less than a threshold).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the networking condition includes an energy level is less than a threshold as taught by Ewing with the method and apparatus for the first device sending a RPC request to the second device and the second device sending a RPC response back to the first device as disclosed by Maddox, as modified by Gidron, for the purpose of reducing data collision, as suggested by Ewing.
Regarding claim 12, Maddox, as modified by Gidron and Ewing, further teaches and discloses a second electronic device (150, figure 1), wherein the second electronic device comprises a processor (processor, 152, figure 1), a memory (memory, 154, figure 1), and a program or an instruction stored in the memory and executable on the processor, and when the program or the instruction is executed by the processor, the network connection method according to claim 5 is implemented ([0013]; [0015]; teaches a second electronic device for performing the method according to claim 5).
Regarding claim 15, Maddox, as modified by Gidron and Ewing, further teaches and discloses a non-transitory readable storage medium, wherein the non-transitory readable storage medium stores a program or an instruction, and when the program or the instruction is executed by a processor, the network connection method according to claim 1 is implemented ([0013]; “…Device…may be a computing device…including hardware such as a processor 112, memory 114, and user and input/output (I/O) interface hardware 116. Device 110 may employ hardware 112, 114, and 116 to implement or execute a user interface and an application 120 responsive to user input. Application 120 may implement or employ the user interface to receive and execute or relay user commands and provide user-friendly output…”; [0014]; teaches a non-transitory readable storage medium for performing the method according to claim 1).
Regarding claim 19, Maddox, as modified by Gidron and Ewing, further teaches and discloses a non-transitory readable storage medium, wherein the non-transitory readable storage medium stores a program or an instruction, and when the program or the instruction is executed by a processor, the network connection method according to claim 5 is implemented ([0013]; “…Device…may be a computing device…including hardware such as a processor 112, memory 114, and user and input/output (I/O) interface hardware 116. Device 110 may employ hardware 112, 114, and 116 to implement or execute a user interface and an application 120 responsive to user input. Application 120 may implement or employ the user interface to receive and execute or relay user commands and provide user-friendly output…”; [0014]; teaches a non-transitory readable storage medium for performing the method according to claim 5).
Claims 2, 3, 6, 7, 9, 10, 13, 14, 16, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Maddox et al. (hereinafter Maddox) (U.S. Patent Application Publication # 2022/0166563 A1) in view of Gidron et al. (hereinafter Gidron) (U.S. Patent Application Publication # 2015/0019620 A1) and Ewing et al. (hereinafter Ewing) (U.S. Patent # 9,503,974 B1), and further in view of Romano et al. (hereinafter Romano) (U.S. Patent # 7,853,962 B1).
Regarding claims 2 and 9, Maddox teaches the first device sending a RPC request to the second device and the second device sending a RPC response back to the first device, but may not explicitly disclose receiving a handle that is of the network interface and that is sent by the second electronic device, wherein the handle comprises first information, the handle is sent by the second electronic device to the first electronic device after the second electronic device calls the network interface and updates the handle of the network interface to the first information, and the first information is used to indicate that the network interface is called through the RPC operation request; storing the handle in a first storage space, wherein the handle is monitored by a multiplex monitoring function; and responding to a networking instruction, and sending the RPC operation request to the second electronic device when it is monitored, by using the multiplex monitoring function, that the handle comprising the first information exists in the first storage space, wherein the RPC operation request further comprises the handle.
Nonetheless, in the same field of endeavor, Romano teaches and suggests receiving a handle (file handle) that is of the network interface and that is sent by the second electronic device (local server, figure 3B), wherein the handle comprises first information, the handle is sent by the second electronic device (local server, figure 3B) to the first electronic device (client, figure 3B) after the second electronic device calls the network interface and updates the handle of the network interface to the first information, and the first information is used to indicate that the network interface is called through the RPC operation request (RPC request; figure 3B); storing the handle in a first storage space (cache/storage, figure 4), wherein the handle is monitored by a multiplex monitoring function; and responding to a networking instruction, and sending the RPC operation request to the second electronic device when it is monitored, by using the multiplex monitoring function, that the handle comprising the first information exists in the first storage space, wherein the RPC operation request further comprises the handle (column 2, lines 16-22; “…SMB protocol identifies the pipe by a logical filename or a file handle of a file that is usually stored on the server that provides the remote service. The client and the remote service exchange RPC requests and RPC responses by reading from and writing to the file that is identified by the logical filename or the file handle…”; column 8, lines 47-57; “…the local server sends a first RPC request to open a transport connection to a RPC service. In the step 204 the local server receives a first RPC response from the RPC service. The first RPC response includes first information which indicates that the transport connection is open. In one embodiment, the transport connection is a pipe mechanism that is implemented as a file stored in the file system of the server that hosts the RPC service. In this embodiment, the first information included in the first RPC response is a file handle to the file representing the pipe…”; column 10, lines 46-50; teaches receiving a file handle sent by the local server for updating information during an RPC operation).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate receiving a file handle sent by the local server for updating information during an RPC operation as taught by Romano with the method and apparatus for the first device sending a RPC request to the second device and the second device sending a RPC response back to the first device as disclosed by Maddox, as modified by Gidron and Ewing, for the purpose of optimization of remote procedure call (RPC) communications, as suggested by Romano.
Regarding claims 3 and 10, Maddox teaches the first device sending a RPC request to the second device and the second device sending a RPC response back to the first device, but may not explicitly disclose responding to the networking instruction, and when it is not monitored, by using the multiplex monitoring function, that the handle comprising the first information exists in the first storage space, calling the network interface call function, and obtaining the response information of the network interface called by the network interface call function.
Nonetheless, in the same field of endeavor, Romano teaches and suggests responding to the networking instruction, and when it is not monitored, by using the multiplex monitoring function, that the handle comprising the first information exists in the first storage space, calling the network interface call function, and obtaining the response information of the network interface called by the network interface call function (column 2, lines 16-22; “…SMB protocol identifies the pipe by a logical filename or a file handle of a file that is usually stored on the server that provides the remote service. The client and the remote service exchange RPC requests and RPC responses by reading from and writing to the file that is identified by the logical filename or the file handle…”; column 8, lines 47-57; “…the local server sends a first RPC request to open a transport connection to a RPC service. In the step 204 the local server receives a first RPC response from the RPC service. The first RPC response includes first information which indicates that the transport connection is open. In one embodiment, the transport connection is a pipe mechanism that is implemented as a file stored in the file system of the server that hosts the RPC service. In this embodiment, the first information included in the first RPC response is a file handle to the file representing the pipe…”; column 10, lines 46-50; teaches receiving a file handle sent by the local server for updating information during an RPC operation).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate receiving a file handle sent by the local server for updating information during an RPC operation as taught by Romano with the method and apparatus for the first device sending a RPC request to the second device and the second device sending a RPC response back to the first device as disclosed by Maddox, as modified by Gidron and Ewing, for the purpose of optimization of remote procedure call (RPC) communications, as suggested by Romano.
Regarding claim 6, Maddox teaches the first device sending a RPC request to the second device and the second device sending a RPC response back to the first device, but may not explicitly disclose wherein a handle of the network interface is second information, and after the calling a network interface call function indicated by the network interface function call number, the method further comprises: updating the handle of the network interface from the second information to first information, wherein the first information is used to indicate that the network interface is called through the RPC operation request; and sending the handle to the first electronic device.
Nonetheless, in the same field of endeavor, Romano teaches and suggests wherein a handle (file handle) of the network interface is second information, and after the calling a network interface call function indicated by the network interface function call number, the method further comprises: updating the handle of the network interface from the second information to first information, wherein the first information is used to indicate that the network interface is called through the RPC operation request (RPC request); and sending the handle to the first electronic device (column 2, lines 16-22; “…SMB protocol identifies the pipe by a logical filename or a file handle of a file that is usually stored on the server that provides the remote service. The client and the remote service exchange RPC requests and RPC responses by reading from and writing to the file that is identified by the logical filename or the file handle…”; column 8, lines 47-57; “…the local server sends a first RPC request to open a transport connection to a RPC service. In the step 204 the local server receives a first RPC response from the RPC service. The first RPC response includes first information which indicates that the transport connection is open. In one embodiment, the transport connection is a pipe mechanism that is implemented as a file stored in the file system of the server that hosts the RPC service. In this embodiment, the first information included in the first RPC response is a file handle to the file representing the pipe…”; column 10, lines 46-50; teaches receiving a file handle sent by the local server for updating information during an RPC operation).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate receiving a file handle sent by the local server for updating information during an RPC operation as taught by Romano with the method and apparatus for the first device sending a RPC request to the second device and the second device sending a RPC response back to the first device as disclosed by Maddox, as modified by Gidron and Ewing, for the purpose of optimization of remote procedure call (RPC) communications, as suggested by Romano.
Regarding claim 7, Maddox teaches the first device sending a RPC request to the second device and the second device sending a RPC response back to the first device, but may not explicitly disclose wherein the calling a network interface call function indicated by the network interface function call number comprises: when it is monitored, by using a multiplex monitoring function, that the handle that is of the network interface and that comprises the second information exists in a second storage space, calling the network interface call function indicated by the network interface function call number; and the method further comprises: receiving the RPC operation request sent by the first electronic device, wherein the RPC operation request further comprises the handle that is of the network interface and that comprises the first information; and updating the received handle from the first information to the second information, and storing an updated handle in the second storage space, wherein the handle is monitored by the multiplex monitoring function.
Nonetheless, in the same field of endeavor, Romano teaches and suggests wherein the calling a network interface call function indicated by the network interface function call number comprises: when it is monitored, by using a multiplex monitoring function, that the handle that is of the network interface and that comprises the second information exists in a second storage space (cache/storage, figure 4), calling the network interface call function indicated by the network interface function call number; and the method further comprises: receiving the RPC operation request sent by the first electronic device, wherein the RPC operation request further comprises the handle that is of the network interface and that comprises the first information; and updating the received handle from the first information to the second information, and storing an updated handle in the second storage space, wherein the handle is monitored by the multiplex monitoring function (column 2, lines 16-22; “…SMB protocol identifies the pipe by a logical filename or a file handle of a file that is usually stored on the server that provides the remote service. The client and the remote service exchange RPC requests and RPC responses by reading from and writing to the file that is identified by the logical filename or the file handle…”; column 8, lines 47-57; “…the local server sends a first RPC request to open a transport connection to a RPC service. In the step 204 the local server receives a first RPC response from the RPC service. The first RPC response includes first information which indicates that the transport connection is open. In one embodiment, the transport connection is a pipe mechanism that is implemented as a file stored in the file system of the server that hosts the RPC service. In this embodiment, the first information included in the first RPC response is a file handle to the file representing the pipe…”; column 10, lines 46-50; teaches receiving a file handle sent by the local server for updating information during an RPC operation).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate receiving a file handle sent by the local server for updating information during an RPC operation as taught by Romano with the method and apparatus for the first device sending a RPC request to the second device and the second device sending a RPC response back to the first device as disclosed by Maddox, as modified by Gidron and Ewing, for the purpose of optimization of remote procedure call (RPC) communications, as suggested by Romano.
Regarding claim 13, Maddux, as modified by Gidron, Ewing, and Romano, further teaches and discloses a second electronic device (150, figure 1), wherein the second electronic device comprises a processor (processor, 152, figure 1), a memory (memory, 154, figure 1), and a program or an instruction stored in the memory and executable on the processor, and when the program or the instruction is executed by the processor, the network connection method according to claim 6 is implemented ([0013]; [0015]; teaches a second electronic device for performing the method according to claim 6).
Regarding claim 14, Maddux, as modified by Gidron, Ewing, and Romano, further teaches and discloses a second electronic device (150, figure 1), wherein the second electronic device comprises a processor (processor, 152, figure 1), a memory (memory, 154, figure 1), and a program or an instruction stored in the memory and executable on the processor, and when the program or the instruction is executed by the processor, the network connection method according to claim 7 is implemented ([0013]; [0015]; teaches a second electronic device for performing the method according to claim 7).
Regarding claim 16, Maddux, as modified by Gidron, Ewing, and Romano, further teaches and discloses a non-transitory readable storage medium, wherein the non-transitory readable storage medium stores a program or an instruction, and when the program or the instruction is executed by a processor, the network connection method according to claim 2 is implemented ([0013]; “…Device…may be a computing device…including hardware such as a processor 112, memory 114, and user and input/output (I/O) interface hardware 116. Device 110 may employ hardware 112, 114, and 116 to implement or execute a user interface and an application 120 responsive to user input. Application 120 may implement or employ the user interface to receive and execute or relay user commands and provide user-friendly output…”; [0014]; teaches a non-transitory readable storage medium for performing the method according to claim 2).
Regarding claim 17, Maddux, as modified by Gidron, Ewing, and Romano, further teaches and discloses a non-transitory readable storage medium, wherein the non-transitory readable storage medium stores a program or an instruction, and when the program or the instruction is executed by a processor, the network connection method according to claim 3 is implemented ([0013]; “…Device…may be a computing device…including hardware such as a processor 112, memory 114, and user and input/output (I/O) interface hardware 116. Device 110 may employ hardware 112, 114, and 116 to implement or execute a user interface and an application 120 responsive to user input. Application 120 may implement or employ the user interface to receive and execute or relay user commands and provide user-friendly output…”; [0014]; teaches a non-transitory readable storage medium for performing the method according to claim 3).
Regarding claim 20, Maddux, as modified by Gidron, Ewing, and Romano, further teaches and discloses a non-transitory readable storage medium, wherein the non-transitory readable storage medium stores a program or an instruction, and when the program or the instruction is executed by a processor, the network connection method according to claim 6 is implemented ([0013]; “…Device…may be a computing device…including hardware such as a processor 112, memory 114, and user and input/output (I/O) interface hardware 116. Device 110 may employ hardware 112, 114, and 116 to implement or execute a user interface and an application 120 responsive to user input. Application 120 may implement or employ the user interface to receive and execute or relay user commands and provide user-friendly output…”; [0014]; teaches a non-transitory readable storage medium for performing the method according to claim 6).
Response to Arguments
Applicant’s arguments, filed July 31, 2026, with respect to the rejection(s) of claim(s) 1-3, 5-10, 12-17, 19, and 20 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Ewing et al. (U.S. Patent # 9,503,974 B1).
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUK JIN KANG whose telephone number is (571) 270-1771. The examiner can normally be reached on Monday-Friday 8am-5pm.
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, Chirag Shah can be reached on (571) 272-3144. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
Any inquiry of a general nature or relating to the status of this application or proceeding should be directed to the receptionist/customer service whose telephone number is (571) 272-2600.
/Suk Jin Kang/
Examiner, Art Unit 2477
October 1, 2026
Prosecution Insights