DETAILED ACTION
This action is responsive to communications filed on May 5, 2024. This action is made Non-Final.
Claims 1-16 are pending in the case.
Claims 1 and 9 are independent claims.
Claims 1-16 are rejected.
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 .
Information Disclosure Statement
The information disclosure statement (IDS(s)) submitted on 08/27/2024 and 02/17/2025 is/are in compliance with the provisions of 37 C.F.R. 1.97. Accordingly, the IDS(s) is/are being considered by the examiner.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “communication hub,” “dynamic layout handler,” and “updater,” in claims 9-16.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 2, 4, 6-10, 12, and 14-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mohler, US Publication 2011/0209069, and further in view of Bihari, US Patent no. 8,156,441 (“Bihari”).
Claim 1:
Mohler teaches or suggests a method for a website building system (WBS), the method comprising:
providing … at least a first third party application and a second third party application having instances in a page of a website of said WBS and, said page having components (see Fig. 1, 2; para. 0040 - "mashup" refers to a web page or application that uses or combines data or functionality from two or many more external sources to create a new service. To be able to permanently access the data of other services, mashups are generally client applications or hosted online; para. 0041 - "mashup editor" refers to a tool or platform for building mashups; para. 0062 - mashup stimulus module where the user makes a request of a new mashup via the user interface, mashup selection and creation modules to perform collectively structured and viral variations on link, system, and application discovery to form the mashup, a mashup configuration module to align mashup and user interface capabilities, provisioning, and preferences, and a mashup management module to coordinate and efficiently manage the mashup and its components; para. 0084 - selects a set of changes to be made to the user interface 120, or a skin for the computational device 108. Useful mashup and/or user interface 120 configuration variations can be requested by the user and discovered by the mashup selection module 164 based on input from the system and/or the existing mashup to create a derivative mashup; para. 0085 - configuration module 168 selects a user interface 120 appearance and/or configuration to be associated with the selected mashup and configures the mashup(s) and their output( s) for presentation; para. 0088 - Mashup creation may be fully automated or interactive with the user or administrator and effected by any suitable technique, such as by mashup editor or enabler.);
handling display changes in said page resulting from at least one dynamic event between said at least first third party application and said second third party application, wherein, said handling display changes comprising changing the size and position of said components on said page in order to preserve the design of said page when said at least one dynamic layout event affects at least one component of said page (see Fig. 1, 2; para. 0023 - changes computational or communication devices; para. 0085 - also to rearrange user interface 120 appearance and/or configuration components as defined by the selected user interface 120 configuration. Rearrangement of the user interface 120 appearance and/or configuration components, for instance, can be selected from a plurality of alternative user interface 120 appearances and/or configurations that the user prefers. appearance and/or configuration that applies to a selected role, context, presence, and/or location would be varied based on the sensed identity or electronic address of the computational device 108 currently in use by the user; para. 0086 – particular mashup configuration, mashup output, and user interface 120 appearance and/or configuration presented to the user normally depends on the capabilities or provisioning of or user preferences for the particular computational device 108 of the user. The mashup is adapted by the mashup configuration module 168 to the capabilities, provisioning, and/or user preferences of the computational device 108. In other words, the configuration and content of the mashup display varies depending on the device capabilities, configurations, provisioning and user preferences. For example, the mashup configuration module 168 can re-arrange or alter the screen appearance and/or configuration, e.g., the icons, menus, sounds, and the like, based on the capabilities of the computational device 108, with the same mashup having differing appearances and/or configurations for different computational devices 108. Device capabilities include, for example, screen or display size, CPUs.); and
adapting said components to said at least one dynamic layout event (see Fig. 1, 2; para. 0023 - changes computational or communication devices; para. 0085 - also to rearrange user interface 120 appearance and/or configuration components as defined by the selected user interface 120 configuration. Rearrangement of the user interface 120 appearance and/or configuration components, for instance, can be selected from a plurality of alternative user interface 120 appearances and/or configurations that the user prefers. appearance and/or configuration that applies to a selected role, context, presence, and/or location would be varied based on the sensed identity or electronic address of the computational device 108 currently in use by the user; para. 0086 – particular mashup configuration, mashup output, and user interface 120 appearance and/or configuration presented to the user normally depends on the capabilities or provisioning of or user preferences for the particular computational device 108 of the user. The mashup is adapted by the mashup configuration module 168 to the capabilities, provisioning, and/or user preferences of the computational device 108. In other words, the configuration and content of the mashup display varies depending on the device capabilities, configurations, provisioning and user preferences. For example, the mashup configuration module 168 can re-arrange or alter the screen appearance and/or configuration, e.g., the icons, menus, sounds, and the like, based on the capabilities of the computational device 108, with the same mashup having differing appearances and/or configurations for different computational devices 108. Device capabilities include, for example, screen or display size, CPUs.).
Mohler does not explicitly disclose 2-way communication between.
Bihari teaches or suggests 2-way communication between (see Fig. 1, 2, 5-9; col. 2, lines 25-48 - inter-gadget communication architecture 10 or framework 10 allows information from different sources 14 to be independently viewed or correlated within the browser 11. The inter-gadget communication architecture 10 or framework 10 comprises a plurality of gadgets 16 that are displayed within the browser 11 and allows data to be communicated between and shared by the gadgets 16; col. 5, lines 9-13 - FIG. 9 shows two inter-communicating gadgets 16 at the upper left portion of the browser window that communicate with each other using inter-gadget communications; col. 10, lines 8-36 - gadget 16 may be an iFrame 17, which can communicate or interact with other gadgets 16 on the same web page. inter-gadget communication architecture 10 or frame-work 10 thus embodies gadgets 16 that export specific methods that can be used by other gadgets 16. By allowing other gadgets 16 to call these exported methods directly on the HTML DOM layer, data can be passed between different gadgets 16. Gadgets 16 can therefore asynchronously pull 30 data from different sources and web services, and through the inter-gadget communication architecture 10 or framework 10, the data can mash-up on the client-side. to either receive or send their data for mashing up; claim 8 - communicates or interacts with other gadgets on the same web page; claim 12 - wherein each respective gadget comprises software code that calls JavaScript methods in other gadgets via an iFrame object array of the web page; para. 0016 - wherein data are communicated between gadget iFrames by controlling session Ids of frame objects on the web page and by passing IGC objects between gadgets.).
Accordingly, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bihari with those of Mohler. One would have been motivated to do so for the purpose of efficiently passing data between applications enabling correlation and viewing of information from different sources, improving user interaction, as taught by Bihari (col. 2, Fig. 8, 9).
Claim 2:
Mohler further teaches or suggests wherein said at least one dynamic layout event is at least one of: a changed view between different display devices; a rotation of a display device between portrait and landscape mode; a change the size or position of at least one component of said page and a content update of at least one component of said page (see Fig. 1, 2; para. 0023 - changes computational or communication devices; para. 0085 - also to rearrange user interface 120 appearance and/or configuration components as defined by the selected user interface 120 configuration. Rearrangement of the user interface 120 appearance and/or configuration components, for instance, can be selected from a plurality of alternative user interface 120 appearances and/or configurations that the user prefers. appearance and/or configuration that applies to a selected role, context, presence, and/or location would be varied based on the sensed identity or electronic address of the computational device 108 currently in use by the user; para. 0086 – particular mashup configuration, mashup output, and user interface 120 appearance and/or configuration presented to the user normally depends on the capabilities or provisioning of or user preferences for the particular computational device 108 of the user. The mashup is adapted by the mashup configuration module 168 to the capabilities, provisioning, and/or user preferences of the computational device 108. In other words, the configuration and content of the mashup display varies depending on the device capabilities, configurations, provisioning and user preferences. For example, the mashup configuration module 168 can re-arrange or alter the screen appearance and/or configuration, e.g., the icons, menus, sounds, and the like, based on the capabilities of the computational device 108, with the same mashup having differing appearances and/or configurations for different computational devices 108. Device capabilities include, for example, screen or display size, CPUs.).
Claim 4:
Mohler further teaches or suggests wherein said first third party application and said second third party application are at least one of a multi-party third party application and a modular third party application (see Fig. 1, 2; para. 0040 - "mashup" refers to a web page or application that uses or combines data or functionality from two or many more external sources to create a new service. To be able to permanently access the data of other services, mashups are generally client applications or hosted online; para. 0041 - "mashup editor" refers to a tool or platform for building mashups; para. 0062 - mashup stimulus module where the user makes a request of a new mashup via the user interface, mashup selection and creation modules to perform collectively structured and viral variations on link, system, and application discovery to form the mashup, a mashup configuration module to align mashup and user interface capabilities, provisioning, and preferences, and a mashup management module to coordinate and efficiently manage the mashup and its components; para. 0084 - selects a set of changes to be made to the user interface 120, or a skin for the computational device 108. Useful mashup and/or user interface 120 configuration variations can be requested by the user and discovered by the mashup selection module 164 based on input from the system and/or the existing mashup to create a derivative mashup; para. 0085 - configuration module 168 selects a user interface 120 appearance and/or configuration to be associated with the selected mashup and configures the mashup(s) and their output( s) for presentation; para. 0088 - Mashup creation may be fully automated or interactive with the user or administrator and effected by any suitable technique, such as by mashup editor or enabler.).
Claim 6:
Mohler does not explicitly disclose wherein said 2-way communication is via at least one of an HTML5 (Hypertext Markup Language 5) PostMessage; a URL fragment identifier for messages, a specialized communication web service, an HTML5 local storage, an HTML5 local file system access APIs and a specialized browser plugin.
Bihari further teaches or suggests wherein said 2-way communication is via at least one of an HTML5 (Hypertext Markup Language 5) PostMessage; a URL fragment identifier for messages, a specialized communication web service, an HTML5 local storage, an HTML5 local file system access APIs and a specialized browser plugin (see Fig. 1, 2, 5-9; col. 2, lines 25-48 - inter-gadget communication architecture 10 or framework 10 allows information from different sources 14 to be independently viewed or correlated within the browser 11. The inter-gadget communication architecture 10 or framework 10 comprises a plurality of gadgets 16 that are displayed within the browser 11 and allows data to be communicated between and shared by the gadgets 16; col. 5, lines 9-13 - FIG. 9 shows two inter-communicating gadgets 16 at the upper left portion of the browser window that communicate with each other using inter-gadget communications; col. 10, lines 8-36 - gadget 16 may be an iFrame 17, which can communicate or interact with other gadgets 16 on the same web page. inter-gadget communication architecture 10 or frame-work 10 thus embodies gadgets 16 that export specific methods that can be used by other gadgets 16. By allowing other gadgets 16 to call these exported methods directly on the HTML DOM layer, data can be passed between different gadgets 16. Gadgets 16 can therefore asynchronously pull 30 data from different sources and web services, and through the inter-gadget communication architecture 10 or framework 10, the data can mash-up on the client-side. to either receive or send their data for mashing up; claim 8 - communicates or interacts with other gadgets on the same web page; claim 12 - wherein each respective gadget comprises software code that calls JavaScript methods in other gadgets via an iFrame object array of the web page; para. 0016 - wherein data are communicated between gadget iFrames by controlling session Ids of frame objects on the web page and by passing IGC objects between gadgets.).
Accordingly, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bihari with those of Mohler. One would have been motivated to do so for the purpose of efficiently passing data between applications enabling correlation and viewing of information from different sources, improving user interaction, as taught by Bihari (col. 2, Fig. 8, 9).
Claim 7:
Mohler further teaches or suggests wherein said fist third part application and said second third party application are embedded in said page (see Fig. 1, 2; para. 0040 - "mashup" refers to a web page or application that uses or combines data or functionality from two or many more external sources to create a new service. To be able to permanently access the data of other services, mashups are generally client applications or hosted online; para. 0041 - "mashup editor" refers to a tool or platform for building mashups; para. 0062 - mashup stimulus module where the user makes a request of a new mashup via the user interface, mashup selection and creation modules to perform collectively structured and viral variations on link, system, and application discovery to form the mashup, a mashup configuration module to align mashup and user interface capabilities, provisioning, and preferences, and a mashup management module to coordinate and efficiently manage the mashup and its components; para. 0084 - selects a set of changes to be made to the user interface 120, or a skin for the computational device 108. Useful mashup and/or user interface 120 configuration variations can be requested by the user and discovered by the mashup selection module 164 based on input from the system and/or the existing mashup to create a derivative mashup; para. 0085 - configuration module 168 selects a user interface 120 appearance and/or configuration to be associated with the selected mashup and configures the mashup(s) and their output( s) for presentation; para. 0088 - Mashup creation may be fully automated or interactive with the user or administrator and effected by any suitable technique, such as by mashup editor or enabler.).
Mohler does not explicitly disclose using an iframe.
Bihari teaches or suggests using an iframe (see Fig. 1, 2, 5-9; col. 2, lines 25-48 - inter-gadget communication architecture 10 or framework 10 allows information from different sources 14 to be independently viewed or correlated within the browser 11. The inter-gadget communication architecture 10 or framework 10 comprises a plurality of gadgets 16 that are displayed within the browser 11 and allows data to be communicated between and shared by the gadgets 16; col. 5, lines 9-13 - FIG. 9 shows two inter-communicating gadgets 16 at the upper left portion of the browser window that communicate with each other using inter-gadget communications; col. 10, lines 8-36 - gadget 16 may be an iFrame 17, which can communicate or interact with other gadgets 16 on the same web page. inter-gadget communication architecture 10 or frame-work 10 thus embodies gadgets 16 that export specific methods that can be used by other gadgets 16. By allowing other gadgets 16 to call these exported methods directly on the HTML DOM layer, data can be passed between different gadgets 16. Gadgets 16 can therefore asynchronously pull 30 data from different sources and web services, and through the inter-gadget communication architecture 10 or framework 10, the data can mash-up on the client-side. to either receive or send their data for mashing up; claim 8 - communicates or interacts with other gadgets on the same web page; claim 12 - wherein each respective gadget comprises software code that calls JavaScript methods in other gadgets via an iFrame object array of the web page; para. 0016 - wherein data are communicated between gadget iFrames by controlling session Ids of frame objects on the web page and by passing IGC objects between gadgets.).
Accordingly, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bihari with those of Mohler. One would have been motivated to do so for the purpose of efficiently passing data between applications enabling correlation and viewing of information from different sources, improving user interaction, as taught by Bihari (col. 2, Fig. 8, 9).
Claim 8:
Mohler further teaches or suggests wherein said adapting comprises updating at least one of an attribute of said WBS, a control permission of at least one of: said at least first third party application and said second third party application and the layout, style and content of components of said page (see Fig. 1, 2; para. 0023 - changes computational or communication devices; para. 0085 - also to rearrange user interface 120 appearance and/or configuration components as defined by the selected user interface 120 configuration. Rearrangement of the user interface 120 appearance and/or configuration components, for instance, can be selected from a plurality of alternative user interface 120 appearances and/or configurations that the user prefers. appearance and/or configuration that applies to a selected role, context, presence, and/or location would be varied based on the sensed identity or electronic address of the computational device 108 currently in use by the user; para. 0086 – particular mashup configuration, mashup output, and user interface 120 appearance and/or configuration presented to the user normally depends on the capabilities or provisioning of or user preferences for the particular computational device 108 of the user. The mashup is adapted by the mashup configuration module 168 to the capabilities, provisioning, and/or user preferences of the computational device 108. In other words, the configuration and content of the mashup display varies depending on the device capabilities, configurations, provisioning and user preferences. For example, the mashup configuration module 168 can re-arrange or alter the screen appearance and/or configuration, e.g., the icons, menus, sounds, and the like, based on the capabilities of the computational device 108, with the same mashup having differing appearances and/or configurations for different computational devices 108. Device capabilities include, for example, screen or display size, CPUs.).
Claim 9:
Mohler teaches or suggests a device for a website building system (WBS), the device comprising:
… embedded in a page of a website of said WBS to implement … at least a first third party application and a second third party application having instances in a page of said website, said page having components (see Fig. 1, 2; para. 0040 - "mashup" refers to a web page or application that uses or combines data or functionality from two or many more external sources to create a new service. To be able to permanently access the data of other services, mashups are generally client applications or hosted online; para. 0041 - "mashup editor" refers to a tool or platform for building mashups; para. 0062 - mashup stimulus module where the user makes a request of a new mashup via the user interface, mashup selection and creation modules to perform collectively structured and viral variations on link, system, and application discovery to form the mashup, a mashup configuration module to align mashup and user interface capabilities, provisioning, and preferences, and a mashup management module to coordinate and efficiently manage the mashup and its components; para. 0084 - selects a set of changes to be made to the user interface 120, or a skin for the computational device 108. Useful mashup and/or user interface 120 configuration variations can be requested by the user and discovered by the mashup selection module 164 based on input from the system and/or the existing mashup to create a derivative mashup; para. 0085 - configuration module 168 selects a user interface 120 appearance and/or configuration to be associated with the selected mashup and configures the mashup(s) and their output( s) for presentation; para. 0088 - Mashup creation may be fully automated or interactive with the user or administrator and effected by any suitable technique, such as by mashup editor or enabler.);
a dynamic layout handler to handle display changes in said page resulting from at least one dynamic layout event between at least said first third party application and said second third party application, wherein said dynamic layout handler changes the size and position of said components on said page in order to preserve the design of said page when said at least one dynamic layout event affects at least one component of said page (see Fig. 1, 2; para. 0023 - changes computational or communication devices; para. 0085 - also to rearrange user interface 120 appearance and/or configuration components as defined by the selected user interface 120 configuration. Rearrangement of the user interface 120 appearance and/or configuration components, for instance, can be selected from a plurality of alternative user interface 120 appearances and/or configurations that the user prefers. appearance and/or configuration that applies to a selected role, context, presence, and/or location would be varied based on the sensed identity or electronic address of the computational device 108 currently in use by the user; para. 0086 – particular mashup configuration, mashup output, and user interface 120 appearance and/or configuration presented to the user normally depends on the capabilities or provisioning of or user preferences for the particular computational device 108 of the user. The mashup is adapted by the mashup configuration module 168 to the capabilities, provisioning, and/or user preferences of the computational device 108. In other words, the configuration and content of the mashup display varies depending on the device capabilities, configurations, provisioning and user preferences. For example, the mashup configuration module 168 can re-arrange or alter the screen appearance and/or configuration, e.g., the icons, menus, sounds, and the like, based on the capabilities of the computational device 108, with the same mashup having differing appearances and/or configurations for different computational devices 108. Device capabilities include, for example, screen or display size, CPUs.); and
an updater to adapt said components according to said at least one dynamic layout event (see Fig. 1, 2; para. 0023 - changes computational or communication devices; para. 0085 - also to rearrange user interface 120 appearance and/or configuration components as defined by the selected user interface 120 configuration. Rearrangement of the user interface 120 appearance and/or configuration components, for instance, can be selected from a plurality of alternative user interface 120 appearances and/or configurations that the user prefers. appearance and/or configuration that applies to a selected role, context, presence, and/or location would be varied based on the sensed identity or electronic address of the computational device 108 currently in use by the user; para. 0086 – particular mashup configuration, mashup output, and user interface 120 appearance and/or configuration presented to the user normally depends on the capabilities or provisioning of or user preferences for the particular computational device 108 of the user. The mashup is adapted by the mashup configuration module 168 to the capabilities, provisioning, and/or user preferences of the computational device 108. In other words, the configuration and content of the mashup display varies depending on the device capabilities, configurations, provisioning and user preferences. For example, the mashup configuration module 168 can re-arrange or alter the screen appearance and/or configuration, e.g., the icons, menus, sounds, and the like, based on the capabilities of the computational device 108, with the same mashup having differing appearances and/or configurations for different computational devices 108. Device capabilities include, for example, screen or display size, CPUs.).
Mohler does not explicitly disclose a communication hub … 2-way communication between.
Bihari teaches or suggests a communication hub … 2-way communication between (see Fig. 1, 2, 5-9; col. 2, lines 25-48 - inter-gadget communication architecture 10 or framework 10 allows information from different sources 14 to be independently viewed or correlated within the browser 11. The inter-gadget communication architecture 10 or framework 10 comprises a plurality of gadgets 16 that are displayed within the browser 11 and allows data to be communicated between and shared by the gadgets 16; col. 5, lines 9-13 - FIG. 9 shows two inter-communicating gadgets 16 at the upper left portion of the browser window that communicate with each other using inter-gadget communications; col. 10, lines 8-36 - gadget 16 may be an iFrame 17, which can communicate or interact with other gadgets 16 on the same web page. inter-gadget communication architecture 10 or frame-work 10 thus embodies gadgets 16 that export specific methods that can be used by other gadgets 16. By allowing other gadgets 16 to call these exported methods directly on the HTML DOM layer, data can be passed between different gadgets 16. Gadgets 16 can therefore asynchronously pull 30 data from different sources and web services, and through the inter-gadget communication architecture 10 or framework 10, the data can mash-up on the client-side. to either receive or send their data for mashing up; claim 8 - communicates or interacts with other gadgets on the same web page; claim 12 - wherein each respective gadget comprises software code that calls JavaScript methods in other gadgets via an iFrame object array of the web page; para. 0016 - wherein data are communicated between gadget iFrames by controlling session Ids of frame objects on the web page and by passing IGC objects between gadgets.).
Accordingly, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bihari with those of Mohler. One would have been motivated to do so for the purpose of efficiently passing data between applications enabling correlation and viewing of information from different sources, improving user interaction, as taught by Mohler (col. 2, Fig. 8, 9).
Claim 10:
Mohler further teaches or suggests wherein said at least one dynamic layout event is at least one of: a changed view between different display devices; a rotation of a display device between portrait and landscape mode; a change the size or position of at least one component of said page and a content update of at least one component of said page (see Fig. 1, 2; para. 0023 - changes computational or communication devices; para. 0085 - also to rearrange user interface 120 appearance and/or configuration components as defined by the selected user interface 120 configuration. Rearrangement of the user interface 120 appearance and/or configuration components, for instance, can be selected from a plurality of alternative user interface 120 appearances and/or configurations that the user prefers. appearance and/or configuration that applies to a selected role, context, presence, and/or location would be varied based on the sensed identity or electronic address of the computational device 108 currently in use by the user; para. 0086 – particular mashup configuration, mashup output, and user interface 120 appearance and/or configuration presented to the user normally depends on the capabilities or provisioning of or user preferences for the particular computational device 108 of the user. The mashup is adapted by the mashup configuration module 168 to the capabilities, provisioning, and/or user preferences of the computational device 108. In other words, the configuration and content of the mashup display varies depending on the device capabilities, configurations, provisioning and user preferences. For example, the mashup configuration module 168 can re-arrange or alter the screen appearance and/or configuration, e.g., the icons, menus, sounds, and the like, based on the capabilities of the computational device 108, with the same mashup having differing appearances and/or configurations for different computational devices 108. Device capabilities include, for example, screen or display size, CPUs.).
Claim 12:
Mohler further teaches or suggests wherein said first third party application and said second third party application are at least one of a multi-party third party application and a modular third party application (see Fig. 1, 2; para. 0040 - "mashup" refers to a web page or application that uses or combines data or functionality from two or many more external sources to create a new service. To be able to permanently access the data of other services, mashups are generally client applications or hosted online; para. 0041 - "mashup editor" refers to a tool or platform for building mashups; para. 0062 - mashup stimulus module where the user makes a request of a new mashup via the user interface, mashup selection and creation modules to perform collectively structured and viral variations on link, system, and application discovery to form the mashup, a mashup configuration module to align mashup and user interface capabilities, provisioning, and preferences, and a mashup management module to coordinate and efficiently manage the mashup and its components; para. 0084 - selects a set of changes to be made to the user interface 120, or a skin for the computational device 108. Useful mashup and/or user interface 120 configuration variations can be requested by the user and discovered by the mashup selection module 164 based on input from the system and/or the existing mashup to create a derivative mashup; para. 0085 - configuration module 168 selects a user interface 120 appearance and/or configuration to be associated with the selected mashup and configures the mashup(s) and their output( s) for presentation; para. 0088 - Mashup creation may be fully automated or interactive with the user or administrator and effected by any suitable technique, such as by mashup editor or enabler.).
Claim 14:
Mohler does not explicitly disclose wherein said 2-way communication is via at least one of an HTML5 (Hypertext Markup Language 5) PostMessage; a URL fragment identifier for messages, a specialized communication web service, an HTML5 local storage, an HTML5 local file system access APIs and a specialized browser plugin.
Bihari further teaches or suggests wherein said 2-way communication is via at least one of an HTML5 (Hypertext Markup Language 5) PostMessage; a URL fragment identifier for messages, a specialized communication web service, an HTML5 local storage, an HTML5 local file system access APIs and a specialized browser plugin (see Fig. 1, 2, 5-9; col. 2, lines 25-48 - inter-gadget communication architecture 10 or framework 10 allows information from different sources 14 to be independently viewed or correlated within the browser 11. The inter-gadget communication architecture 10 or framework 10 comprises a plurality of gadgets 16 that are displayed within the browser 11 and allows data to be communicated between and shared by the gadgets 16; col. 5, lines 9-13 - FIG. 9 shows two inter-communicating gadgets 16 at the upper left portion of the browser window that communicate with each other using inter-gadget communications; col. 10, lines 8-36 - gadget 16 may be an iFrame 17, which can communicate or interact with other gadgets 16 on the same web page. inter-gadget communication architecture 10 or frame-work 10 thus embodies gadgets 16 that export specific methods that can be used by other gadgets 16. By allowing other gadgets 16 to call these exported methods directly on the HTML DOM layer, data can be passed between different gadgets 16. Gadgets 16 can therefore asynchronously pull 30 data from different sources and web services, and through the inter-gadget communication architecture 10 or framework 10, the data can mash-up on the client-side. to either receive or send their data for mashing up; claim 8 - communicates or interacts with other gadgets on the same web page; claim 12 - wherein each respective gadget comprises software code that calls JavaScript methods in other gadgets via an iFrame object array of the web page; para. 0016 - wherein data are communicated between gadget iFrames by controlling session Ids of frame objects on the web page and by passing IGC objects between gadgets.).
Accordingly, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bihari with those of Mohler. One would have been motivated to do so for the purpose of efficiently passing data between applications enabling correlation and viewing of information from different sources, improving user interaction, as taught by Mohler (col. 2, Fig. 8, 9).
Claim 15:
Mohler further teaches or suggests wherein said fist third part application and said second third party application are embedded in said page (see Fig. 1, 2; para. 0040 - "mashup" refers to a web page or application that uses or combines data or functionality from two or many more external sources to create a new service. To be able to permanently access the data of other services, mashups are generally client applications or hosted online; para. 0041 - "mashup editor" refers to a tool or platform for building mashups; para. 0062 - mashup stimulus module where the user makes a request of a new mashup via the user interface, mashup selection and creation modules to perform collectively structured and viral variations on link, system, and application discovery to form the mashup, a mashup configuration module to align mashup and user interface capabilities, provisioning, and preferences, and a mashup management module to coordinate and efficiently manage the mashup and its components; para. 0084 - selects a set of changes to be made to the user interface 120, or a skin for the computational device 108. Useful mashup and/or user interface 120 configuration variations can be requested by the user and discovered by the mashup selection module 164 based on input from the system and/or the existing mashup to create a derivative mashup; para. 0085 - configuration module 168 selects a user interface 120 appearance and/or configuration to be associated with the selected mashup and configures the mashup(s) and their output( s) for presentation; para. 0088 - Mashup creation may be fully automated or interactive with the user or administrator and effected by any suitable technique, such as by mashup editor or enabler.).
Mohler does not explicitly disclose using an iframe.
Bihari teaches or suggests using an iframe (see Fig. 1, 2, 5-9; col. 2, lines 25-48 - inter-gadget communication architecture 10 or framework 10 allows information from different sources 14 to be independently viewed or correlated within the browser 11. The inter-gadget communication architecture 10 or framework 10 comprises a plurality of gadgets 16 that are displayed within the browser 11 and allows data to be communicated between and shared by the gadgets 16; col. 5, lines 9-13 - FIG. 9 shows two inter-communicating gadgets 16 at the upper left portion of the browser window that communicate with each other using inter-gadget communications; col. 10, lines 8-36 - gadget 16 may be an iFrame 17, which can communicate or interact with other gadgets 16 on the same web page. inter-gadget communication architecture 10 or frame-work 10 thus embodies gadgets 16 that export specific methods that can be used by other gadgets 16. By allowing other gadgets 16 to call these exported methods directly on the HTML DOM layer, data can be passed between different gadgets 16. Gadgets 16 can therefore asynchronously pull 30 data from different sources and web services, and through the inter-gadget communication architecture 10 or framework 10, the data can mash-up on the client-side. to either receive or send their data for mashing up; claim 8 - communicates or interacts with other gadgets on the same web page; claim 12 - wherein each respective gadget comprises software code that calls JavaScript methods in other gadgets via an iFrame object array of the web page; para. 0016 - wherein data are communicated between gadget iFrames by controlling session Ids of frame objects on the web page and by passing IGC objects between gadgets.).
Accordingly, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bihari with those of Mohler. One would have been motivated to do so for the purpose of efficiently passing data between applications enabling correlation and viewing of information from different sources, improving user interaction, as taught by Bihari (col. 2, Fig. 8, 9).
Claim 16:
Mohler further teaches or suggests wherein said adapting comprises updating at least one of an attribute of said WBS, a control permission of at least one of: said at least first third party application and said second third party application and the layout, style and content of components of said page (see Fig. 1, 2; para. 0023 - changes computational or communication devices; para. 0085 - also to rearrange user interface 120 appearance and/or configuration components as defined by the selected user interface 120 configuration. Rearrangement of the user interface 120 appearance and/or configuration components, for instance, can be selected from a plurality of alternative user interface 120 appearances and/or configurations that the user prefers. appearance and/or configuration that applies to a selected role, context, presence, and/or location would be varied based on the sensed identity or electronic address of the computational device 108 currently in use by the user; para. 0086 – particular mashup configuration, mashup output, and user interface 120 appearance and/or configuration presented to the user normally depends on the capabilities or provisioning of or user preferences for the particular computational device 108 of the user. The mashup is adapted by the mashup configuration module 168 to the capabilities, provisioning, and/or user preferences of the computational device 108. In other words, the configuration and content of the mashup display varies depending on the device capabilities, configurations, provisioning and user preferences. For example, the mashup configuration module 168 can re-arrange or alter the screen appearance and/or configuration, e.g., the icons, menus, sounds, and the like, based on the capabilities of the computational device 108, with the same mashup having differing appearances and/or configurations for different computational devices 108. Device capabilities include, for example, screen or display size, CPUs.).
Claim(s) 3 and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mohler, in view of Bihari, and further in view of Mentchoukov et al., US Publication 2011/0320529 (“Mentchoukov”).
Claim 3:
Mentchoukov more specifically teaches or suggests wherein said content update is from at least one of: a server based update or a runtime update (see Fig. 4; para. 0019 - leverage unused space on a client display to present secondary content secondary content. may be published and/or accessed from an entity other than the provider of the primary content (e.g., from another network-accessible service, web server, or the like); para. 0028 - user resizes the client application display area 112, resulting in updates to the unused space 166 and corresponding virtual board 167. Similar updates may occur in response to dynamic changes in the primary content 120 and/or 122. For example, the primary content 120 and/or 122 may be dynamically updated (re rendered), resulting in updates to the identified unused space and/or corresponding virtual board; spara. 0036 - content may be received from a network-accessible service via a network communication interface (e.g., a web server); para. 0038 - determining the position, size, and/or orientation of other elements on the client display (e.g., other application windows); para. 0050 - secondary content may be displayed by another application or in response to receiving the secondary content) provided by the content distribution service or another content provider; para. 0051 - dynamically adaptable to differently sized and/or proportioned placeholders.).
Accordingly, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Mentchoukov with those of Mohler. One would have been motivated to do so for the purpose of efficiently rendering multiple different snippets or applications in a dynamic interface or browser based on user interaction or device capabilities and leveraging unused space, improving user interaction, as taught by Mentchoukov (0019, 0028, 0038).
Claim 11:
Mentchoukov more specifically teaches or suggests wherein said content update is from at least one of: a server based update or a runtime update (see Fig. 4; para. 0019 - leverage unused space on a client display to present secondary content secondary content. may be published and/or accessed from an entity other than the provider of the primary content (e.g., from another network-accessible service, web server, or the like); para. 0028 - user resizes the client application display area 112, resulting in updates to the unused space 166 and corresponding virtual board 167. Similar updates may occur in response to dynamic changes in the primary content 120 and/or 122. For example, the primary content 120 and/or 122 may be dynamically updated (re rendered), resulting in updates to the identified unused space and/or corresponding virtual board; spara. 0036 - content may be received from a network-accessible service via a network communication interface (e.g., a web server); para. 0038 - determining the position, size, and/or orientation of other elements on the client display (e.g., other application windows); para. 0050 - secondary content may be displayed by another application or in response to receiving the secondary content) provided by the content distribution service or another content provider; para. 0051 - dynamically adaptable to differently sized and/or proportioned placeholders.).
Accordingly, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Mentchoukov with those of Mohler. One would have been motivated to do so for the purpose of efficiently rendering multiple different snippets or applications in a dynamic interface or browser based on user interaction or device capabilities and leveraging unused space, improving user interaction, as taught by Mentchoukov (0019, 0028, 0038).
Claim(s) 5 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mohler, in view of Bihari, and further in view of Amadio et al., US Publication 2007/0214431 (“Amadio”).
Claim 5:
Mohler does not explicitly disclose wherein said adapting comprises cascading style sheets.
Amadio teaches or suggests wherein said adapting comprises cascading style sheets (see Fig. 2A-2E, and 3-11; para. 0034 - information can be accessed by a user for display in an adjustable way and arranged in an orderly fashion on the display according to the user's preferences; para. 0043 - the dynamic information elements (306-310) within a designated area 305 may be resized within the designated area as necessary; para. 0065 - dynamic information element may be resized by a "world transform" in a Windows Presentation Framework, a "zoom factor," or via a CSS property in HTML; para. 0073 - method of resizing the dynamic information element may further depend on a specific technology used such as windows Presentation Framework or via the CSS (Cascading Style Sheets) property in HTML.).
Accordingly, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Amadio with those of Mohler. One would have been motivated to do so for the purpose of efficiently efficiently enabling access to information in an adjustable way and arranged in an orderly fashion using CSS, improving user interaction, as taught by Amadio (0034, 0065, and 0073).
Claim 13:
Mohler does not explicitly disclose wherein said adapting comprises cascading style sheets.
Amadio teaches or suggests wherein said adapting comprises cascading style sheets (see Fig. 2A-2E, and 3-11; para. 0034 - information can be accessed by a user for display in an adjustable way and arranged in an orderly fashion on the display according to the user's preferences; para. 0043 - the dynamic information elements (306-310) within a designated area 305 may be resized within the designated area as necessary; para. 0065 - dynamic information element may be resized by a "world transform" in a Windows Presentation Framework, a "zoom factor," or via a CSS property in HTML; para. 0073 - method of resizing the dynamic information element may further depend on a specific technology used such as windows Presentation Framework or via the CSS (Cascading Style Sheets) property in HTML.).
Accordingly, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Amadio with those of Mohler. One would have been motivated to do so for the purpose of efficiently efficiently enabling access to information in an adjustable way and arranged in an orderly fashion using CSS, improving user interaction, as taught by Amadio (0034, 0065, and 0073).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Andrew T McIntosh whose telephone number is (571)270-7790. The examiner can normally be reached M-Th 8:00am-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Tamara Kyle can be reached at 571-272-4241. 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.
/ANDREW T MCINTOSH/Primary Examiner, Art Unit 2144
