DETAILED ACTION
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 .
Response to Amendment
2. This communication is in response to the amendment filed on 12/01/2025. The Examiner has acknowledged the amended Claims 1-6 and 9. Claims 1-9 are pending, and Claims 1-9 are rejected.
Response to Arguments
3. Applicant's arguments (Remarks: Pages: 9-11) filed on 12/01/2025 have been fully considered but they are not persuasive and/or now moot in view of the new ground of rejection necessitated by applicant's amendment.
4. Certified copies of the Priority documents received on 10/20/2025.
5. The objections to the Claims 3 and 6-7 have been withdrawn in view of the amended corrections.
6. The rejection of Claims 4-5 and 9 under 35 U.S.C 112 (b) has been withdrawn in view of the amended corrections.
7. Applicant’s arguments (Remarks: Pages: 9-11) with respect to 35 U.S.C. 103 have been fully considered but they are not persuasive and/or now moot in view of the new ground of rejection necessitated by applicant's amendment.
Applicant argues in Remarks [Pages 9-11]:
“Amended independent claim 1 outlines a specific sequence performed by the
first control unit of the information processing apparatus in response to its start-up process….,
However, Sathyadevan does not teach or suggest any structured, multi-step process performed by the gateway device itself that corresponds to the claimed operations, particularly the execution of communication settings, security mode notification, and subsequent linking to a terminal device based on those settings, and
Applicant has also considered Horita, and respectfully submits that Horita fails to overcome the above-noted deficiencies of Sathyadevan with regard to the subject
matter of amended independent claim 1.”
Examiner respectfully disagrees. Sathyadevan discloses that Middleware core 206 maintains device identification, addressing and other gateway profile information of all registered IoT gateways 202 (1-n) (Sathyadevan: ¶[0043]), and when the device boots on the network (i.e. when the device initiates) the middleware may check the ID of the gateway against the stored ID to identify the gateway device and may then update the status of the device to REGISTER (Sathyadevan: ¶[0048]). Sathyadevan further discloses that middleware router 205 requests for active gateway devices in each startup operation and creates gateway routes based on that reply (i.e. establish communication routes for registered devices) (Sathyadevan: ¶[0042]). In addition, Sathyadevan discloses security protocol handling of registered devices, for example, Middleware core handle different types of gateway responses with respect to context and protocols (Sathyadevan: ¶[0047]), where the IoT gateway device hardware (Beagle Bone) includes a few security features such as data encryption, authentication, secure booting, and features for securing data in transmission (Sathyadevan: ¶[0070], also see ¶ [0071]).
In addition, Horita discloses the subsequent linking to a terminal device based on the communication settings as discussed in the 35 U.S.C.103 rejection below (Please see the rejection below).
Therefore, the combination of Sathyadevan and Horita discloses the features that the applicant is arguing about and thus, applicant’s arguments are not persuasive.
Further, applicant’s arguments with respect to Claim 6 and the dependent claims are based on applicant’s arguments with respect to Claim 1 and their respective dependency and are rejected using similar rationales discussed above with respect to Claim 1.
Applicant's amendment necessitated a new ground of rejection.
Claim Rejections - 35 USC § 103
8. 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.
9. 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.
10. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
11. Claims 1-9 are rejected under 35 U.S.C. 103 as being unpatentable over Sathyadevan et al. (S 20170094033 Al, hereinafter Sathya) in view of Horita et al. (US 2011/0176432 A1, hereinafter Horita).
Regarding Claim 1,
Sathya discloses an information processing apparatus connected between a terminal device and a server apparatus that communicates with the terminal device via a network, the information processing apparatus comprising (Sathya: [Abstract] A gateway device has a CPU, a power source, a digital memory, physical communication ports and wireless communication
circuitry receiving data from data-gathering devices, an interface to a wide-area network, dedicated hardware pipelines managing the data received, See Fig. 2, ¶ [0038-0040]):
a first communication unit to be connected to the server apparatus via the network (Sathya: ¶ [0040] Gateway devices 202 (1-n) route data through access point 209 to middleware (SW) depicted herein as a middleware cloud 204. Middleware cloud 204 may be thought of as an upper platform in the IoT infrastructure where data received over the network from registered IoT gateway devices is processed, ¶ [0032-0036, 0041] Also see Fig. 2—204, 202);
a second communication unit to be connected to the terminal device (Sathya: ¶ [0039] gateway devices 202 (1-n) are distributed on an Ethernet network or local area network
(L AN)…, Each IoT gateway device 202 (1-n) has communication with one or more than one sub device(D) 203 (1-n)…, IoT gateway-I (202 (1)) receives data from sub-devices D-1, D-2, and D-3 (203 (1-3)). IoT gateway-2 receives data from sub-devices D-4 and D-5. Sub-devices D-6, D-7, and D-8 send data to IoT gateway device-3. Sub devices D-9-Dn send data to IoT gateway-n on the network, ¶ [0012, 0026, 0032-0036], also see Fig. 2—204, 203); and
a first control unit configured to, in response to initiation of a start-up process of the information processing apparatus (Sathya: ¶ [0048] gateway becoming active or "booting" on the network of a middleware server, ¶[0027] Gateway device 100 in this example includes a microprocessor, a random access memory (RAM), a graphics accelerator, an Advanced RISC Machine (ARM) cortex processor, and at least one computer processing unit (CPU) adapted to host software applications that may add functionality to the device, Figs. 1, 2—100, 104, 202, 206):
cause the first communication unit to link up to a communication management apparatus (Sathya: ¶ [0048] gateway becoming active or "booting" on the network of a middleware server sends an ACTIVEGW command to the middleware core…, Middleware core 206 may use a command REGISTER to register a new IoT gateway on the network, ¶[0027] Gateway device 100 in this example includes a microprocessor, a random access memory (RAM), a graphics accelerator, an Advanced RISC Machine (ARM) cortex processor, and at least one computer processing unit (CPU) adapted to host software applications that may add functionality to the device, Figs. 1, 2—100,104, 202, 206);
execute, upon confirming that the information processing apparatus is recognized by the communication management apparatus, communication setting based on communication setting information indicating whether the terminal device is allowed to communicate with another terminal device (Sathya: ¶ [0043] Middleware core 206 maintains device identification, addressing and other gateway profile information of all registered IoT gateways 202 (1-n), ¶ [0048] When the device boots on the network the middleware may check the ID of the gateway against the stored ID to identify the gateway device and may then update the status of the device to REGISTER, ¶ [0042] middleware router 205 requests for active gateway devices in each startup operation and creates gateway routes based on that reply…, gateway device "listens" to middleware for an incoming ID request. (2) iotmkgatewayid>/response. The gateway device responds to each middle request. (3) iotm/setup. This channel is a global channel that listens to the network for common set up information. (4) iotmkgatewayid>stream. The gateway device sends streaming data from one or more sub devices ¶ [0049]);
notify the communication management apparatus that a security mode is turned on after the communication setting is completed (Sathya: ¶ [0047] Middleware core 206 may process all user requests, check the state and health of each active gateway, and handle different types of gateway responses with respect to context and protocols, ¶ [0070] The IoT gateway device hardware (Beagle Bone) includes a few security features such as data encryption, authentication, secure booting, and features for securing data in transmission, ¶ [0071] supports Secure Boot, VPN/SSL endpoint, Hardware digital wallet, Random number generator, Authentication Device and AES 128 Encryption in hardware, ¶ [0122] Gateway responds with unique gateway ID for authenticating on the network, ¶¶ [0095, 0119]); and
cause the second communication unit to link up to the terminal device in accordance with the communication setting (Sathya: ¶ [0042] middleware router 205 requests for active gateway devices in each startup operation and creates gateway routes based on that reply…, gateway device "listens" to middleware for an incoming ID request. (2) iotmkgatewayid>/response. The gateway device responds to each middle request. (3) iotm/setup. This channel is a global channel that listens to the network for common set up information. (4) iotmkgatewayid>stream. The gateway device sends streaming data from one or more sub devices).
Sathya does not explicitly execute, upon confirming that the information processing apparatus is recognized by the communication management apparatus, communication setting based on communication setting information indicating whether the terminal device is allowed to communicate with another terminal device.
However, Horita from the same field of endeavor as the claimed invention discloses communication system controller stores therein an ad-hoc radio communication permission table indicating permission or non-permission of each of direct radio communications between the respective radio terminal apparatuses (Horita: [Abstract]), an in-flight space 50 of the airplane, radio terminal apparatuses 40-1 and 40-2 (denoted generically by a numerical reference 40 hereinafter) are installed at respective passenger seats whose positions are previously determined. A communication system controller 10 is a control apparatus for controlling radio communications
in the whole radio LAN system (Horita: ¶ [0069], See also Fig. 1), an ad-hoc radio communication permission table 6a for storing data indicating permission or non-permission of the ad-hoc radio communication between the respective radio terminal apparatuses 40 (Horita: ¶[0075], also see ¶ [0076]), and stores therein application programs executed by the main controller 1 and data for executing the application programs, the ad-hoc radio communication permission table 6a, and the communication status table 6b. The communication interface 7 is connected to the respective radio base station apparatuses 30 via the LAN 60 (Horita: ¶[0079], ¶ [0080]).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Horita in the teachings of Sathya. A person having ordinary skill in the art would have been motivated to do so because the communication system controller 10 can allocate the channel or ESS-ID optimum for the ad-hoc mode communication between the radio terminal apparatuses 40 to the pair of radio terminal apparatuses 40, by controlling the communication status of all of the radio terminal apparatuses
40 using the communication status table 6b (Horita: ¶ [0095]), and to ensure only trusted devices can interact with each other.
Regarding Claim 2,
Claim 2 is dependent on Claim 1, and the combination of Sathya and Horita discloses all the limitations of Claim 1. Sathya further discloses wherein the first control unit acquires communication setting information applied to the information processing apparatus from the communication management apparatus to which the first communication unit is linked up, and executes communication setting, based on the communication setting information acquired from the communication management apparatus (Sathya: ¶ [0042] middleware router 205 requests for active gateway devices in each startup operation and creates gateway routes based on that reply…, gateway device "listens" to middleware for an incoming ID request. (2) iotmkgatewayid>/response…, This channel is a global channel that listens to the network for common set up information. (4) iotmkgatewayid> stream, ¶ [0048] gateway device responds with the unique ID which may be stored by the middleware. When the device boots on the network the middleware may check the ID of the gateway against the stored ID to identify the gateway device and may then update the status of the device to REGISTER, ¶ [0043], also see Fig 2).
Regarding Claim 3,
Claim 3 is dependent on Claim 1, and the combination of Sathya and Horita discloses all the limitations of Claim 1. Sathya further discloses further comprising: a storage unit that stores communication setting information applied to the information processing apparatus, wherein the first control unit executes communication setting, based on the communication setting information stored in the storage unit (Sathya: ¶ [0009] computerized gateway device is provided, comprising a central processing unit (CPU), a power source, a digital memory coupled to the CPU, ¶ [0048] middleware core may ask for a unique gateway internal ID stored on the gateway device to be registered, ¶¶ [0122, 0123]).
Regarding Claim 4,
Claim 4 is dependent on Claim 1, and the combination of Sathya and Horita discloses all the limitations of Claim 1. Sathya further discloses wherein the first control unit causes the second communication unit to link up to a plurality of terminal devices to be managed, after communication settings in all information processing apparatuses connected to the plurality of terminal devices are completed (Sathya: ¶ [0039] gateway devices 202 (1-n) are distributed on an Ethernet network or local area network (L AN)…, Each IoT gateway device 202 (1-n) has communication with one or more than one sub device(D) 203 (1-n)…, IoT gateway-I (202 (1)) receives data from sub-devices D-1, D-2, and D-3 (203 (1-3)). IoT gateway-2 receives data from sub-devices D-4 and D-5. Sub-devices D-6, D-7, and D-8 send data to IoT gateway device-3. Sub devices D-9-Dn send data to IoT gateway-n on the network, ¶ [0042] gateway device responds to each middle request. (3) iotm/setup. This channel is a global channel that listens to the network for common set up information. (4)iotmkgatewayid>stream. The gateway device sends streaming data from one or more sub devices).
Regarding Claim 5,
Claim 5 is dependent on Claim 4, and the combination of Sathya and Horita discloses all the limitations of Claim 4. Sathya further discloses wherein the first control unit causes the second communication unit to link up to the plurality of terminal devices after receiving, from the communication management apparatus, a notification indicating that communication settings have been completed in all of the information processing apparatuses connected to the plurality of terminal devices to be managed (Sathya: ¶ [0027] Gateway device 100 in this example includes a microprocessor, a random access memory (RAM), a graphics accelerator, an Advanced RISC Machine (ARM) cortex processor, and at least one computer processing unit (CPU) adapted to host software applications that may add functionality to the device ¶ [0041] the required capability to manage multiple different streams of data incoming from different end devices such as devices 203 (1-n), ¶ [0042] Middleware router 205 may specify static routs in a spring xml file. Middleware router 205 may create dynamic routes on the fly or as needed. In one implementation middleware router 205 requests for active gateway devices in each startup operation and creates gateway routes based on that reply…, gateway device responds to each middle request. (3) iotm/setup. This channel is a global channel that listens to the network for common set up information. ( 4) iotmkgatewayid>stream. The gateway device sends streaming data from one or more sub devices, ¶ [0043] Middleware core 206 maintains device identification, addressing and other gateway profile information of all registered IoT gateways 202 (1-n)…., carrying out a registration process for each connected gateway, ¶ [0048] When the device boots on the network the middleware may check the ID of the gateway against the stored ID to identify the gateway device and may then update the status of the device to REGISTER (i.e. each gateway has to register with middleware cloud in order to communicate), ¶¶ [0040, 0049-0051, 0119]).
Regarding Claim 6,
Sathya discloses a communication system comprising (Sathya: ¶ [0025] provides a unique system for communicating over a network with dynamic support for communications protocols, See fig. 2-i.e. system of devices):
a plurality of information processing apparatuses and a communication management apparatus (Sathya: Fig. 2—202 (1-n) IOT gateways, 204 middleware cloud (205, 206, 207), ¶ [0042] middleware router 205 requests for active gateway devices in each startup operation and creates gateway routes based on that reply…, gateway device "listens" to middleware for an incoming ID request, ¶[0043] Middleware core 206 maintains device identification, addressing and other gateway profile information of all registered IoT gateways 202 (1-n)) wherein each of the information processing apparatuses includes (Sathya: Fig. 2—202 (1-n) IOT gateways):
a first communication unit to be connected to a server apparatus via a network (Sathya: ¶ [0040] Gateway devices 202 (1-n) route data through access point 209 to middleware (SW) depicted herein as a middleware cloud 204. Middleware cloud 204 may be thought of as an upper platform in the IoT infrastructure where data received over the network from registered IoT gateway devices is processed, ¶ [0032-0036, 0041] Also see Fig. 2—204, 202);
a second communication unit to be connected to a terminal device that outputs information to be supplied to the server apparatus (Sathya: ¶ [0039] gateway devices 202 (1-n) are distributed on an Ethernet network or local area network (L AN)…, Each IoT gateway device 202 (1-n) has communication with one or more than one sub device(D) 203 (1-n)…, IoT gateway-I (202 (1)) receives data from sub-devices D-1, D-2, and D-3 (203 (1-3)). IoT gateway-2 receives data from sub-devices D-4 and D-5. Sub-devices D-6, D-7, and D-8 send data to IoT gateway device-3. Sub devices D-9-Dn send data to IoT gateway-n on the network, ¶ [0042] The gateway device sends streaming data from one or more sub devices, ¶¶ [0012, 0026, 0032-0036], also see Fig. 2—204, 203); and
a first control unit configured to, in response to initiation of a start-up process of the information processing apparatus (Sathya: ¶ [0048] gateway becoming active or "booting" on the network of a middleware server, ¶[0027] Gateway device 100 in this example includes a microprocessor, a random access memory (RAM), a graphics accelerator, an Advanced RISC Machine (ARM) cortex processor, and at least one computer processing unit (CPU) adapted to host software applications that may add functionality to the device, Figs. 1, 2—100, 104, 202, 206):
cause the first communication unit to link up to the communication management apparatus (Sathya: ¶ [0048] gateway becoming active or "booting" on the network of a middleware server sends an ACTIVEGW command to the middleware core…, Middleware core 206 may use a command REGISTER to register a new IoT gateway on the network, ¶[0027] Gateway device 100 in this example includes a microprocessor, a random access memory (RAM), a graphics accelerator, an Advanced RISC Machine (ARM) cortex processor, and at least one computer processing unit (CPU) adapted to host software applications that may add functionality to the device, Figs. 1, 2—100,104, 202, 206);
execute, upon confirming that the information processing apparatus is recognized by the communication management apparatus, communication setting based on communication setting information indicating whether or not communications between the terminal device and another terminal device are enabled (Sathya: ¶ [0042] middleware router 205 requests for active gateway devices in each startup operation and creates gateway routes based on that reply…, gateway device "listens" to middleware for an incoming ID request. (2) iotmkgatewayid>/response. The gateway device responds to each middle request. (3) iotm/setup. This channel is a global channel that listens to the network for common set up information. (4) iotmkgatewayid>stream. The gateway device sends streaming data from one or more sub devices, ¶ [0043] Middleware core 206 maintains device identification, addressing and other gateway profile information of all registered IoT gateways 202 (1-n), ¶ [0048] When the device boots on the network the middleware may check the ID of the gateway against the stored ID to identify the gateway device and may then update the status of the device to REGISTER, ¶¶ [0012, 0026, 0031-0036, 0041, 0049], Figs. 1, 2—100,104, 202, 206);
notify the communication management apparatus that a security mode is turned on after the communication setting is completed (Sathya: ¶ [0047] Middleware core 206 may process all user requests, check the state and health of each active gateway, and handle different types of gateway responses with respect to context and protocols, ¶ [0070] The IoT gateway device hardware (Beagle Bone) includes a few security features such as data encryption, authentication, secure booting, and features for securing data in transmission, ¶ [0071] supports Secure Boot, VPN/SSL endpoint, Hardware digital wallet, Random number generator, Authentication Device and AES 128 Encryption in hardware, ¶ [0122] Gateway responds with unique gateway ID for authenticating on the network, ¶¶ [0095, 0119]); and
cause the second communication unit to link up to the terminal device in accordance with the communication setting (Sathya: ¶ [0042] middleware router 205 requests for active gateway devices in each startup operation and creates gateway routes based on that reply…, gateway device "listens" to middleware for an incoming ID request. (2) iotmkgatewayid>/response. The gateway device responds to each middle request. (3) iotm/setup. This channel is a global channel that listens to the network for common set up information. (4) iotmkgatewayid>stream. The gateway device sends streaming data from one or more sub devices), and
wherein the communication management apparatus includes (Sathya: ¶ [0043]):
a network (NW) communication unit that communicates with each of the information processing apparatuses via the network (Sathya: ¶ [0048] gateway becoming active or "booting" on the network of a middleware server sends an ACTIVEGW command to the middleware core…, Middleware core 206 may use a command REGISTER to register a new IoT gateway on the network, ¶¶ [0032-0036, 0041] , See Fig. 2 -Gateways connecting to Middleware Cloud); and
a second control unit configured to: manage security information used for communications which the NW communication unit performs between each of the information processing apparatuses and another apparatus (Sathya: ¶ [0047] Middleware core 206 may process all user requests, check the state and health of each active gateway, and handle different types of gateway responses with respect to context and protocols, ¶¶ [0048, 0070-0071], also see Fig. 3);
recognize the information processing apparatus that has linked up to the communication management apparatus via the NW communication unit in the start-up process (Sathya: ¶ [0042] middleware router 205 requests for active gateway devices in each startup operation and creates gateway routes based on that reply…, gateway device "listens" to middleware for an incoming ID request. (2) iotmkgatewayid>/response. The gateway device responds to each middle request. (3) iotm/setup. This channel is a global channel that listens to the network for common set up information. (4) iotmkgatewayid>stream. The gateway device sends streaming data from one or more sub devices, ¶ [0043] Middleware core 206 maintains device identification, addressing and other gateway profile information of all registered IoT gateways 202 (1-n), ¶ [0048] When the device boots on the network the middleware may check the ID of the gateway against the stored ID to identify the gateway device and may then update the status of the device to REGISTER, ¶¶ [0032-0036, 0041, 0047] , See Fig. 2 -Gateways connecting to Middleware Cloud); and
recognize the information processing apparatus whose security mode is turned on by the notification (Sathya: ¶ [0047] Middleware core 206 may process all user requests, check the state and health of each active gateway, and handle different types of gateway responses with respect to context and protocols, ¶ [0070] The IoT gateway device hardware (Beagle Bone) includes a few security features such as data encryption, authentication, secure booting, and features for securing data in transmission, ¶ [0071] supports Secure Boot, VPN/SSL endpoint, Hardware digital wallet, Random number generator, Authentication Device and AES 128 Encryption in hardware, ¶ [0122] Gateway responds with unique gateway ID for authenticating on the network, ¶¶ [0095, 0119]).
Sathya does not explicitly disclose execute, upon confirming that the information processing apparatus is recognized by the communication management apparatus, communication setting based on communication setting information indicating whether or not communications between the terminal device and another terminal device are enabled.
However, Horita from the same field of endeavor as the claimed invention discloses communication system controller stores therein an ad-hoc radio communication permission table indicating permission or non-permission of each of direct radio communications between the respective radio terminal apparatuses (Horita: [Abstract]), an in-flight space 50 of the airplane, radio terminal apparatuses 40-1 and 40-2 (denoted generically by a numerical reference 40 hereinafter) are installed at respective passenger seats whose positions are previously determined. A communication system controller 10 is a control apparatus for controlling radio communications
in the whole radio LAN system (Horita: ¶ [0069], See also Fig. 1), an ad-hoc radio communication permission table 6a for storing data indicating permission or non-permission of the ad-hoc radio communication between the respective radio terminal apparatuses 40 (Horita: ¶[0075], also see ¶ [0076]), and stores therein application programs executed by the main controller 1 and data for executing the application programs, the ad-hoc radio communication permission table 6a, and the communication status table 6b. The communication interface 7 is connected to the respective radio base station apparatuses 30 via the LAN 60 (Horita: ¶[0079], ¶ [0080]).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Horita in the teachings of Sathya. A person having ordinary skill in the art would have been motivated to do so because the communication system controller 10 can allocate the channel or ESS-ID optimum for the ad-hoc mode communication between the radio terminal apparatuses 40 to the pair of radio terminal apparatuses 40, by controlling the communication status of all of the radio terminal apparatuses
40 using the communication status table 6b (Horita: ¶ [0095]), and to ensure only trusted can devices can interact with each other.
Regarding Claim 7,
Claim 7 is dependent on Claim 6, and the combination of Sathya and Horita discloses all the limitations of Claim 6. Sathya further discloses wherein the communication management apparatus further includes a storage unit that stores communication setting information applied to each of the information processing apparatuses (Sathya: ¶ [0047] Middleware core 206 may process all user requests, check the state and health of each active gateway, and handle different types of gateway responses with respect to context and protocols, ¶ [0048] gateway device responds with the unique ID which may be stored by the middleware. When the device boots on the network the middleware may check the ID of the gateway against the stored ID, ¶ [0043] Middleware core 206 maintains device identification, addressing and other gateway profile information of all registered IoT gateways 202 (1-n)), and
the second control unit of the communication management apparatus reads communication setting information applied to the information processing apparatuses with which the communications by the NW communication unit are established (Sathya: ¶ [0043] Middleware core 206 maintains device identification, addressing and other gateway profile information of all registered IoT gateways 202 (1-n) ¶ [0047] Middleware core 206 may process all user requests, check the state and health of each active gateway, and handle different types of gateway responses with respect to context and protocols, ¶¶ [0048, 0070-0071] also see Fig. 3), and
transmits the communication setting information to the information processing apparatuses (Sathya: ¶ [0042] middleware router 205 requests for active gateway devices in each startup operation and creates gateway routes based on that reply…, gateway device "listens" to middleware for an incoming ID request…, ¶ [0043] gateways 202 (1-n) may perform one or more actions based on requests from middleware core server 206. Each gateway 202
(1-n) responds to each request received from the middleware platform, also see Fig 2), and the first control unit of each of the information processing apparatuses acquires communication setting information from the communication management apparatus to which the first communication unit has linked up, and executes communication setting, based on the communication setting information acquired from the communication management apparatus (Sathya: ¶ [0048] gateway becoming active or "booting" on the network of a middleware server sends an ACTIVEGW command to the middleware core…, Middleware core 206 may use a command REGISTER to register a new IoT gateway on the network, ¶[0027] Gateway device 100 in this example includes a microprocessor, a random access memory (RAM), a graphics accelerator, an Advanced RISC Machine (ARM) cortex processor, and at least one computer processing unit (CPU) adapted to host software applications that may add functionality to the device, ¶¶ [0012, 0026, 0032-0036,0031 0042, 00043], Figs. 2—202, 206).
Regarding Claim 8,
Claim 8 is dependent on Claim 6, and the combination of Sathya and Horita discloses all the limitations of Claim 6. The combination of Sathya and Horita discloses all the limitations of Claim 8 as discussed in Claim 3. Therefore, Claim 8 is rejected using the same rationales as discussed in Claim 3.
Regarding Claim 9,
Claim 9 is dependent on Claim 6, and the combination of Sathya and Horita discloses all the limitations of Claim 6. Sathya further discloses wherein the second control unit of the communication management apparatus (Sathya: ¶ [0047] Middleware core 206 may process all user requests, check the state and health of each active gateway, and handle different types of gateway responses with respect to context and protocols, ¶¶ [0048, 0070-0071] also see Fig. 3) transmits a completion notification of communication setting to each of the information processing apparatuses to be managed (Sathya: ¶ [0039] gateway devices 202 (1-n) are distributed on an Ethernet network or local area network (L AN)…, Each IoT gateway device 202 (1-n) has communication with one or more than one sub device(D) 203 (1-n)…, IoT gateway-I (202 (1)) receives data from sub-devices D-1, D-2, and D-3 (203 (1-3)). IoT gateway-2 receives data from sub-devices D-4 and D-5. Sub-devices D-6, D-7, and D-8 send data to IoT gateway device-3. Sub devices D-9-Dn send data to IoT gateway-n on the network, ¶ [0042] gateway device responds to each middle request (3) iotm/setup. This channel is a global channel that listens to the network for common set up information. (4)iotmkgatewayid>stream. The gateway device sends streaming data from one or more sub devices), in a case where communication settings are recognized as being completed in all of the information processing apparatuses connected to a plurality of terminal devices to be managed, and the first control unit of each of the information processing apparatuses causes the second communication unit to link up to the plurality of terminal devices, after receipt of the completion notification of communication setting indicating that communication settings have been completed in all of the information processing apparatuses connected to the plurality of terminal devices to be managed (Sathya: ¶ [0027] Gateway device 100 in this example includes a microprocessor, a random access memory (RAM), a graphics accelerator, an Advanced RISC Machine (ARM) cortex processor, and at least one computer processing unit (CPU) adapted to host software applications that may add functionality to the device ¶ [0041] the required capability to manage multiple different streams of data incoming from different end devices such as devices 203 (1-n) (i.e. terminal devices), ¶ [0042] Middleware router 205 may specify static routs in a spring xml file. Middleware router 205 may create dynamic routes on the fly or as needed. In one implementation middleware router 205 requests for active gateway devices in each startup operation and creates gateway routes based on that reply…, gateway device responds to each middle request. (3) iotm/setup. This channel is a global channel that listens to the network for common set up information. ( 4) iotmkgatewayid>stream. The gateway device sends streaming data from one or more sub devices (i.e. terminal devices are linked up), ¶ [0043] Middleware core 206 maintains device identification, addressing and other gateway profile information of all registered IoT gateways 202 (1-n)…., carrying out a registration process for each connected gateway, ¶ [0048] When the device boots on the network the middleware may check the ID of the gateway against the stored ID to identify the gateway device and may then update the status of the device to REGISTER (i.e. each gateway has to register with middleware cloud in order to communicate), ¶¶ [0040, 0049-0051, 0119]).
Conclusion
12. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US-20200204549-A1
US-20180338242-A1
US-20200244297-A1
US-20170169640-A1
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMEERA WICKRAMASURIYA whose telephone number is (571)272-1507. The examiner can normally be reached on M-F 9:45am - 6:15pm.
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, Jung W. Kim can be reached on 571-272-3804. 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.
/SAMEERA WICKRAMASURIYA/
Examiner, Art Unit 2494
/JUNG W KIM/Supervisory Patent Examiner, Art Unit 2494